| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Graham,
Thanks for your comments, see my response inline in blue font.
Best Regards
Jay Yang (���)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
Hi Jay,
I have been re-reading your 23/1324 document. I apologize if I do not understand this case well, but I would like to ask a few questions. Your answers might clear this whole thin up for me.
First about the Beacon Request.
In your text you seem to indicate that a STA will use both IRM and â??device IDâ??. Did you mean this? should it not be one or the other? Is there any reason for a STA to use both? Maybe should be written to make that clear?
--><Jay> It's true that the Beacon Request can carry one or more optional subelements . In general, I think it's enough for the Beacon Request to carry one of them, measurement ID or IRM recommendation, but I admit the current proposed text don't exclude the both cases you mentioned. I will add a sentence to preclude the both cases if both sides support the two features.
If the STA associates to the AP using an IRM (say IRM 1), then when it goes away to send the probe to another BSSID , the STA can use any TA is wants? i.e., an RMA , but technically it is still associated to the first AP? The STA should not indicate IRM active to the other AP.
--><Jay> According to the analysis in 1453r1, I understand the STA can use any TA in the probe in post association. Due to the privacy protection consideration, the STA may adopt a different RMA in each probe or change the TA in period. Anyway, it's the implementation strategy. For your second question, yes, the STA don't carry RSNE/RSNXE element in the probe.
The other AP does not need to know precisely who this STA is, does it? BUT when the STA reports back to its original AP, it must use the same TA (IRM 1) as it remained associated, and is identified. Hence, with IRM I see no problem identifying the STA. Is that right?
--><Jay> The puropose is to identify the STA by the other AP, not the associated AP. More explaination see below:
The purpose is to let other AP in the same ESS filter out the target STA based on the certain identifier. Before 11aq implementation, the STA always using the fixed MAC address. If the ESS intends to get some RF situation between the STA1 and AP2, the ESS will tell the AP1 to send a Beacon request to STA1, to trigger STA1 send probe request frame on AP2's operating channel. Meanwhile, the ESS tell the AP2 to capture the probe and report STA1's RF situation to the ESS based on STA's fixed MAC address. Based on that, a simple way to address such implemantion broken issue caused by 11aq is that the ESS tell the STA1 send a probe with a certain 11bh identifier via the Beacon request sent by the AP1, while AP2 capures the probe based on the same 11bh identifier.
If using device ID. When STA associated it either provided or was provided with a device ID. Again, the STA does not need to declare that ID to the other AP does it?
Maybe I am not understanding fully, but in the Beacon request case, I donâ??t see a problem.
Now if the probes are being used to gauge signal strength as a STA probes different APs in an ESS , then in this case, let me see if I have this right.
Before associating with any AP in the ESS , if STA using IRM , then STA probes each AP in the ESS using the same TA which may be an RMA . The STA may then be steered to a particular AP and at that point the STA will associate using an IRM (if it has been there before) or provides a new IRM for the next time. The TA must remain constant throughout the ESS until the STA associates, at which time it may associate as usual with IRM . Note that while probing, the STA should not indicate IRM active.
--><Jay> I don't propose the RSNE/RSNXE carried in the probe. But not sure what's the meaning of "The TA must remain constant throughout the ESS until the STA associates". I believe we already fully discussed when the STA use the same MAC in 1453r1 during the call or in the reflector. When the STA use the same MAC address? follows the rule defined in 12.2.10.
In short, the STA can use any MAC address in the probe, IRM or RMA according to current rule.
If using Device ID, again, the device ID is not used until the STA actually is associating with the chosen AP. I donâ??t see why a device ID is used for the probing, the same TA takes care of identification of the STA at this point.
--><Jay> I will keep neutral attitude whether the Device ID can be carried in a general probe, we can discuss it later in CID 171.
In order to distinguish from the general Device ID, i will use measurement ID concept in my proposal according to the group feedback. I propose the impementation can adopt the measurement ID solution if the STA doesn't support IRM. Otherwise, the use case of client steering and off-channel Wi-Fi senesing in post assoication are still broken caused by 11aq.
If the STA has associated first with an AP in the ESS , then in this case the TA is fixed and is the IRM , but I donâ??t think that is the Use Case, right?
Now, I accept that I may have this wrong, and if so please explain. At the moment Iâ??m not sure I understand all your text additions in 23/1314.
Thanks for tackling this problem,
Best regards
Graham
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