| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Mark, On 9/1/23, 10:25 AM, "Mark Hamilton" <mark.hamilton2152@xxxxxxxxx> wrote: Dan/Jay/all, I might be missing some of what Jay is trying to point out – please respond if there is more, Jay. But, I have a couple comments, if I can jump into this thread:
-
@Harkins, Dan: Jay pointed out below what I think is just a typo: The
frames are called “Beacon Request” and “Beacon Report”. There is no “Beacon Report Request” – I think you meant just “Beacon Request”. Thank you, yes.
-
Dan asks below: >>> “When STA1 sends a probe request to AP2 what shared state is it creating?”
o
I would respond: The state is that STA1 is able to hear both AP1 and AP2, and some information about the link quality between STA1 and each of those APs. This state information can be gathered by both the AP and the STA, during
a Beacon report scanning (probing). The STA will report the information in the actual Beacon Report. The APs may also create their own state information based on the reception of the Probe Requests, but that only works if the APs can identify the Probe Request(s)
that are from STA1. That's not shared state. Gathering information about RF conditions through probing or scanning or whatever may create state on the STA doing the probing and scanning but the AP doesn't create the same state and bind the STAs MAC address
to it. For the purposes of band steering an AP may create state regarding who it is that's probing the AP in an effort to not answer if the desire is to steer the STA to another band but that is not state that the STA even knows is being created nor is it
state that the STA can refer to later with a particular MAC address. But in general I don't believe APs fill up memory with "I got probed by MAC-X" state because they get probed a lot.
When talking about these transactional exchanges, they are things that create the same stuff on both the STA and AP. Think of SAE. Or FILS. Pre-auth is another example of creating shared state between a STA and and AP that can be referred
to later by using the MAC bound to that state. Just gathering some requested environmental data is not a transactional exchange because there's really no transaction made when gathering said data. Probe request, probe response. End of exchange. No transaction,
no state retained. There is nothing the STA expects the AP to have that it would use on a future connection. But with SAE there is. There is an exchange of 802.11 authentication frames and the end result should be a PMKSA on both the STA and AP. When the STA
wants to use that state to association it must revert back to the MAC address it used to create that PMKSA. A STA could do SAE with AP1 using MAC1, do SAE with AP2 using MAC2, and SAE with AP3 using MAC3. Now it has shared state, each bound to a unique MAC
address, on 3 APs in the ESS. If it later wants to go associate with AP2 it will change its MAC address to MAC2 and associate. But a probe? No, there's no shared state bound to a MAC address that the STA will want to refer to later. It's not a transactional
exchange. regards, Dan. -- "the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." – Marcus Aurelius Mark From: Harkins, Dan <daniel.harkins@xxxxxxx>
Hi Jay, On 8/31/23, 11:26 PM, "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx> wrote: Hi Dan, The state created on the AP and STA is per-AP level, not per-BSS. After the STA associated with the AP(AP1),the STA can send Class1/2/3 frame to AP1. But the
STA is only allowed to send Class 1 frame to the second AP(AP2). e.g. the STA can't send Class 3 frame, like Data frame, to AP2. Obviously, the STA is in the state 1 from AP2 perspective. So? I don't understand what point you're making here. Yes, the state governs what frames can be sent. And…. When we talk "transactional exchange", i guess there is a precondition to say the transactional exchange shall be between one entity peer, like AP1 and STA1
is an entity peer, while STA1 and AP2 is the another entity peer. If so, beacon request/report between AP1/STA1 is a transactional exchange, while probe request/response between STA1/AP2 is another transactional exchange. It looks like one transactional exchange
insert into the procedure of another transactional exchange. Maybe I'm totally wrong as 11aq doesn't describe this part very clear. The transactional exchange generates shared state. If there is no shared state created then it's not a transactional exchange—"starts any transaction that establishes state bound to a MAC". Let me ask my question below again. When STA1 sends a probe request to AP2 what shared state is it creating? Or is it using some state it created due to the fact that its associated with AP1? If so how? regards, Dan. -- "the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." – Marcus Aurelius
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
Original From: Harkins ,Dan <daniel.harkins@xxxxxxx> To: 杨志杰10343608;STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
<STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>; Date: 2023年09月01日
11:02 Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Hi Jay,
The question is, does the STA doing the probing require the use of any state it had created on an AP in the ESS to perform its activities? If so then what is that state?
Is this a transactional exchange or not? The fact that there might be 4 types of frame exchanges does not affect the answer. So? What's the answer? You don't need to wait until Tuesday, you can answer now.
regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
On 8/31/23, 6:28 PM, "Jay Yang" <yang.zhijie@ZTE .COM.CN> wrote:
Hi Dan, I have a quick look at your contribution. I've some hard time to understand the question "Is
a probe made in response to a Beacon Report Request a transactional exchange? ". There are 4 type of frames exchange in this procedure: Beacon request, Beacon report, probe request
and probe response. Beacon report is the response to the Beacon request. So not sure what's the meaning "Beacon Report Request" here. Anyway, I'm happy to discuss more with you next Tues.
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
Original
From: MarkHamilton <mark.hamilton2152@xxxxxxxxx>
Date: 2023年09月01日
03:59
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Thanks, Dan. I’ve added it.
Mark
From: Harkins , Dan <daniel.harkins@xxxxxxx>
Hi Mark,
I've uploaded document 11-23/1453r0 to mentor. Can you put me on the agenda for the next teleconference on 5 September please?
thanks and regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 |