Subject: [manet] 802.11 NAV setting in overlapping BSS case

From: Yue Fang <[email-masked]>
Date: Mon, 18 Apr 2005 16:42:54 -0400 (EDT)

Dear manet users:

I have a couple of questions regarding the 802.11 nav setting in
overlapping BSS cases, could you please share your understanding of these
issues? Thanks in advance.

1. As the general NAV setting, in the protocol, section 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."

My questions are:
a: Does it imply that STAs in DCF will not differentiate frames from
other BSS?
b: If a STA receives a CFP data frame from another BSS, since the
duration field is set to 32768, what will it do?

2 As the NAV setting in CFP, in section 9.3.2.2: "Each STA, except
the STA with the PC, shall preset its NAV to the CFPMaxDuration value
(obtained from the CF Parameter Set elements in beacons from this PC) at
each target beacon transmission time (TBTT) at which a CFP is scheduled to
start (based on the CFPPeriod field in the CF Parameter Set element of the
beacon frames from this PC). Each non-PC STA shall update its NAV using
the CFDurRemaining value in any error-free CF Parameter Set element of the
Beacon frame that the STA receives. This includes CFPDurRemaining values
in CF Parameter Set elements from beacon frames from other (overlapping)
BSS"

My question is, is this rule only applies to STA that operate in CFP?
similarly like question 1, if a STA works in CP hears the beacon from
another CFP BSS contains CFPDurRemaining value, what does it do?

Any input is appreciated.

Bests
Yue

-----------------------------------
Yue Fang
227 Egan Research Building
Dept. of Electrical & Computer Eng.
Northeastern University
Boston, MA, 02115
(tel) 617-373-3009
-----------------------------------

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: David Young <[email-masked]>
Date: Mon, 18 Apr 2005 17:26:00 -0500

> a: Does it imply that STAs in DCF will not differentiate frames from

Yes.

> b: [...]

I do not know the answer to your question regarding the CFP.

Dave

-- 
David Young             OJC Technologies
[email-masked]      Urbana, IL * (217) 278-3933

---

From: Jim Thompson <[email-masked]>
Date: Mon, 18 Apr 2005 15:33:20 -1000

>>a: Does it imply that STAs in DCF will not differentiate frames from
I don't think so. 

 From IEEE-802.11-1999 (7.2.2):

    A station uses the contents of the Address 1 field to perform 
address matching for receive decisions.
    In cases where the Address 1 field contains a group address, the 
BSSID also is validated to ensure
    that the broadcast or multicast originated in the same BSS.

So certainly if its a group addressed (multicast, broadcast) frame, then 
the BSSID is consulted.  Otherwise,
if addr1 matches, then the packet is received.

This leaves open the possibility that a given STA could be associated 
with more than one AP, but 5.4.2.2 says:

    "At any given instant, a STA may be associated with no more than one 
AP. This ensures that the DS may
    determine a unique answer to the question, "Which AP is serving STA 
X?" Once an association is
    completed, a STA may make full use of a DS (via the AP) to 
communicate. Association is always initiated by
    the mobile STA, not the AP."

Since each AP is its on BSS, any given STA can't be associated with more 
than one AP, and the combination of
BSSID+RA *has* to be unique, the answer is 'STAs in DCF will certainly 
differentiate frames from other BSS'.

Frames in an IBSS always have "FromDS" and "ToDS" clear, and there can 
only (are only supposed to) be a single IBSS in a given environment.  
(IEEE-802.11-1999.5.6)

    "An IBSS consists of STAs that are directly connected. Thus there is 
(by definition) only one BSS."

>>duration field is set to 32768, what will it do?
If the the STA in another (I)BSS does this, its misbehaving, for 
starters.

---

From: David Young <[email-masked]>
Date: Mon, 18 Apr 2005 21:30:19 -0500

> >>a: Does it imply that STAs in DCF will not differentiate frames from

Jim,

I think your understanding of Yue Fang's question is different from mine.
I understood his question (a) to implicitly begin, "For the purpose of
updating its NAV, ...".  I do not believe a STA will differentiate frames
from another BSS, when it comes to updating its NAV.  (Consider the case
of RTS/CTS/ACK packets, whose BSS you cannot always infer.)

Dave

---

From: Jim Thompson <[email-masked]>
Date: Tue, 19 Apr 2005 00:46:46 -1000

>of RTS/CTS/ACK packets, whose BSS you cannot always infer.)
Dave,

Every control frame (RTS, CTS, ACK, CF-END, CF-END+CF-ACK) except 
PS-POLL has a RA in it.   This RA must
match, in the case of CF-END, CF-END+CF-ACK and ACK.

RTS and CTS frames will cross BSS boundries.  This is by design.  
Perhaps this is the question Yue Fang was asking.

RTS and CTS can't be used for group-addressed frames, btw.

The duration for CF-END and CF-END+CF-ACK, is 0.   The duration for RTS, 
CTS and ACK all follow similar
rules, which I won't repeat here (7.1.2 for those who want to go look.)

PS-POLL has a TA and BSSID in it, such that any STA can tell if the 
PS-POLL is something it should
pay attention to.  Upon reception of a PS-POLL (for the BSSID to which 
the STA belongs)

     "All STAs, upon receipt of a PS-Poll frame, update their NAV 
settings as appropriate under
    the coordination function rules using a duration value equal to the 
time, in microseconds,
    required to transmit one ACK frame plus one SIFS interval."

---

From: Yue Fang <[email-masked]>
Date: Tue, 19 Apr 2005 09:58:52 -0400 (EDT)

> (by definition) only one BSS."

hello, Jim:

If we consider that two IBSSs located close enough that STAs from one
BSS may overhear the transmission from another BSS. In this case, let's
assume a STA received a data packet transmitted in another BSS, should it
update its NAV to defer channel access? I think it should even though
it is originated and addressed to STA in another BSS otherwise
transmission from this STA may cause collision at the other end.

> If the the STA in another (I)BSS does this, its misbehaving, for

As in previous case, the CFP frame is not addressed to this STA, but since
there are overlapping BSS, the STA may overhear the CFP transmission from
another BSS, what should we do? This is more difficult for me since there
is no duration information contained in CFP data frame. Even we can update
NAV, we don't know which value we should use.

---

From: Jim Thompson <[email-masked]>
Date: Tue, 19 Apr 2005 11:10:52 -1000

>transmission from this STA may cause collision at the other end.
potentially, but there is no requirement in the specification for this 
behavior,
and normal filtering will mean that the card rejects the packet.

Note that CCA is still a requirement, so if the two STAs are close 
enough that they
can hear each other, it is likely that they will not co-interfere.

The situation becomes problematic when one of the STAs is receiving a 
packet that doesn't set CCA
in the second STA.  The second STA is free to transmit.

Your solution doesn't help, since the second STA couldn't decode the 
packet (by definition).

RTS/CTS *might* help in this situation, and is part of the reason that 
RTS and CTS packets were designed
to cross BSS boundries.

>NAV, we don't know which value we should use.
On a second reading, I don't think that the CFP is even defined when 
operating in IBSS mode.

To your question, all communcation during the CFP is initiated by the PC 
(which is the AP).
The duration infomation during the CFP is carried by the PS-POLL frame, 
which would proceed any
data frame transmitted by any associated STA, so the PS-POLL is used to 
update the NAV.

Special considerations concerning operation with overlapping 
point-coordinated BSSs is covered in section 9.3.3.2 of the standard.

jim