The need for the ACK frame

Hi,

I was digging into the 802.11 specification, and was trying to imagine
a scenario where even when the sender transmits the RTS and the
receiver transmits the CTS, the ACK frame is *needed* so that the
sender can detect possible collisions. I mean, I'm trying to figure
out an scenario that shows why the RTS/CTS/ACK sequence is needed,
instead of just having a RTS/CTS sequence.

Here's the scenario I think would demonstrate it:

There's a Wireless LANs of four hosts,

A ------- B --------- C --------- D


in which each host can hear only the adjacent hosts (i.e., A can hear
only B, B can hear only A and C, and so on).

A desires to transmit a packet, so it transmits a RTS.
B responds it with a CTS.
As D cannot hear B, it transmits a frame.
B's and D's frames collide at C.
C detects the collision, and therefore waits for a period of time
equal to EIFS, and then backoffs.
After this, if C has a frame to send, it will transmit an RTS frame,
which will possibly collide (at B) with A's data frame.

So A might think the frame was transmitted correctly, while a
collision occured at B. This demonstrates that in order for A to be
assured that the frame was successfully received, an ACKnowledgement
of the received frame is needed.

Any comments?

--
Fernando Gont
e-mail: (E-Mail Removed)

[To send a personal reply, please remove the ANTISPAM tag]

RTS/CTS and ACK serve complementary, but different, functions. The purpose
of the RTS/CTS handshake is to avoid a collision. The purpose of ACK is to
confirm that a frame was received free of error.

Collision is only one reason a frame might be received in error. Even if
RTS/CTS is in effect, a transmitted frame can be garbled by interference,
multipath echo, a wonky antenna at the receiving station, or a host of other
problems. Since collision detection is not possible, ACK timeout is the only
way to determine that something went wrong.

Your scenario sounds like an ad-hoc network with stations communicating
directly. RTS/CTS is less effective in ad-hoc networks because, as you note,
not all stations can "hear" each other (hidden node problem). RTS/CTS does
not kick in as a result of experiencing a collision, as your example seems
to imply. An RTS is sent prior to any data frame whose length exceeds a
configurable threshold value. In an ad-hoc network, it's sent to the station
that should receive the data frame, and that station is required to respond
with a CTS when it believes the network is not busy.

In an infrastructure network, all stations communicate via the AP, and
therefore by definition they can all "hear" the AP. If station A wants to
send a large frame to station D (large enough to trigger RTS/CTS), then it
sends RTS to the AP (not to D), and the AP sends back CTS when it believes
the network is idle, A sends the data frame to the AP (not to D), and the AP
sends the data frame to D. So, RTS/CTS solves the hidden node problem in an
infrastructure network, but not in an ad-hoc network.

"Fernando Gont" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi,
>
> I was digging into the 802.11 specification, and was trying to imagine
> a scenario where even when the sender transmits the RTS and the
> receiver transmits the CTS, the ACK frame is *needed* so that the
> sender can detect possible collisions. I mean, I'm trying to figure
> out an scenario that shows why the RTS/CTS/ACK sequence is needed,
> instead of just having a RTS/CTS sequence.
>
> Here's the scenario I think would demonstrate it:
>
> There's a Wireless LANs of four hosts,
>
> A ------- B --------- C --------- D
>
>
> in which each host can hear only the adjacent hosts (i.e., A can hear
> only B, B can hear only A and C, and so on).
>
> A desires to transmit a packet, so it transmits a RTS.
> B responds it with a CTS.
> As D cannot hear B, it transmits a frame.
> B's and D's frames collide at C.
> C detects the collision, and therefore waits for a period of time
> equal to EIFS, and then backoffs.
> After this, if C has a frame to send, it will transmit an RTS frame,
> which will possibly collide (at B) with A's data frame.
>
> So A might think the frame was transmitted correctly, while a
> collision occured at B. This demonstrates that in order for A to be
> assured that the frame was successfully received, an ACKnowledgement
> of the received frame is needed.
>
> Any comments?
>
> --
> Fernando Gont
> e-mail: (E-Mail Removed)
>
> [To send a personal reply, please remove the ANTISPAM tag]
>

On Thu, 18 Dec 2003 08:20:00 GMT, "gary" <(E-Mail Removed)>
wrote:

>Collision is only one reason a frame might be received in error. Even if
>RTS/CTS is in effect, a transmitted frame can be garbled by interference,
>multipath echo, a wonky antenna at the receiving station, or a host of other
>problems.

Sure, but.... isn't the ACK meant for the possible collisions, rather
than for the other possible causes, etc.?

I have not read the entire specification, but as the RTS/CTS/ACK are
part of the *MAC* sublayer, I don't think it's meant to provide a
*reliable* transfer. (i.e., reliability should be provided by the LLC
sublayer).


>Your scenario sounds like an ad-hoc network with stations communicating
>directly. RTS/CTS is less effective in ad-hoc networks because, as you note,
>not all stations can "hear" each other (hidden node problem).

Well, the RTS/CTS mechanism is supposed to help in that situatio: The
sender sends an RTS, so that all hosts that can hear only the sender
will know about the transmission, while the receiver sends a CTS, so
that all hosts that can hear only the receiver know about the future
transmission, too.



>RTS/CTS does
>not kick in as a result of experiencing a collision, as your example seems
>to imply.

My example tries to show that there are some scenarios where the
RTS/CTS mechanism cannot avoid collisions.

In a fairly simple scenario, such as:

A ---- B ---- C

where each node can hear only adjacent ones, the RTS/CTS mechanism
does solve the "hidden node" problem. That's why I tried to figure out
an scenario where "hidden nodes" can not be solved by just the RTS/CTS
sequence.

--
Fernando Gont
e-mail: (E-Mail Removed)

[To send a personal reply, please remove the ANTISPAM tag]

"Fernando Gont" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Thu, 18 Dec 2003 08:20:00 GMT, "gary" <(E-Mail Removed)>
> wrote:
>
> >Collision is only one reason a frame might be received in error. Even if
> >RTS/CTS is in effect, a transmitted frame can be garbled by interference,
> >multipath echo, a wonky antenna at the receiving station, or a host of
other
> >problems.
>
> Sure, but.... isn't the ACK meant for the possible collisions, rather
> than for the other possible causes, etc.?

No, it's the one-and-only transmitter error detection mechanism. This goes
back to the Aloha network, the granddaddy of packet radio. On a shared wired
medium like Ethernet, a transmitter can detect collision fragments at the
MAC sublayer and abort transmission early by sending a jam signal. This
reduces the effect of collision on throughput, because you don't have to
wait for a whole frame to finish transmitting before you figure out that it
won't make it. With radio, you send a frame out there and you have no way of
knowing what happened to it unless somebody signals back that they got it.
Since in general a receiver can't know that a frame was headed its way,
there's no point in having a NACK protocol for partially-received frames
since it won't handle frames that are completely lost. The best solution is
a positive ACK scheme with a timeout on the transmitter, which is the only
station that reliably knows that the frame ever existed. As a result,
interference and collision have a much worse effect on wifi networks than on
classical Ethernet.

>
> I have not read the entire specification, but as the RTS/CTS/ACK are
> part of the *MAC* sublayer, I don't think it's meant to provide a
> *reliable* transfer. (i.e., reliability should be provided by the LLC
> sublayer).

It's not there for reliable transfer, it's there for transmitter error
detection, which is a primary responsibility of the MAC. Error detection at
the MAC sublayer can trigger LLC retransmit, even if the LLC is not using
its own ACK protocol.

>
>
> >Your scenario sounds like an ad-hoc network with stations communicating
> >directly. RTS/CTS is less effective in ad-hoc networks because, as you
note,
> >not all stations can "hear" each other (hidden node problem).
>
> Well, the RTS/CTS mechanism is supposed to help in that situatio: The
> sender sends an RTS, so that all hosts that can hear only the sender
> will know about the transmission, while the receiver sends a CTS, so
> that all hosts that can hear only the receiver know about the future
> transmission, too.

As you have pointed out, the receiver has to hear the sender in order to
respond with CTS. In an infrastructure network, RTS is always transmitted
*to the AP* and CTS is always transmitted *from the AP*. It's a star
topology, with the AP acting as hub. By definition, all stations in an
infrastructure net can talk to the AP, so the hidden node problem is
completely solved.

In an ad-hoc net, as you say, RTS/CTS may be less effective if there are
hidden nodes. It depends on the connectivity graph of the stations. Your
three-station scenario partitions the net into two overlapping cells - cell
1 contains stations A and B, cell 2 contains B and C. Within each cell, all
stations can talk to each other, but only B lives in both cells. A and C
don't see each other, so no tranmission ever takes place between them. All
traffic is between A or C and B. If B initiates an RTS/CTS conversation with
A, then C will not hear A's CTS (it hears B's RTS, but is required to ignore
it). In general, RTS/CTS has a failure mode for *any* ad-hoc network with a
hidden node.

Now generalize a bit - let cell 1 and cell 2 each contain an arbitrary
number of stations. B remains the only station that everybody can talk to,
but all stations in cell 1 can talk to each other, and ditto for cell 2. Now
suppose two stations in cell 1 start an RTS/CTS conversation, and neither
one is B. Then no station in cell 2 receives the CTS, and so RTS/CTS fails
if the stations in cell 1 generate enough power to interfere with
transmissions in cell 2. The network can be partitioned in arbitrarily
complex ways by hidden nodes.

>
>
>
> >RTS/CTS does
> >not kick in as a result of experiencing a collision, as your example
seems
> >to imply.
>
> My example tries to show that there are some scenarios where the
> RTS/CTS mechanism cannot avoid collisions.
>
> In a fairly simple scenario, such as:
>
> A ---- B ---- C
>
> where each node can hear only adjacent ones, the RTS/CTS mechanism
> does solve the "hidden node" problem. That's why I tried to figure out
> an scenario where "hidden nodes" can not be solved by just the RTS/CTS
> sequence.

See above for two examples.

>
> --
> Fernando Gont
> e-mail: (E-Mail Removed)
>
> [To send a personal reply, please remove the ANTISPAM tag]