| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Antonio, Hi Phil Please see my answers inline below.
(in Blue) Best regards. Stéphane. From: Philip Hawkes <000047a0059a9b2d-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Antonio, I have responses inline below (in
green font starting [PH]) to your questions about generation of EDP FA Block. Cheers,Phil From: Antonio DeLaOlivaDelgado <aoliva@xxxxxxxx> WARNING: This email
originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Dear, I have several CIDs asking to describe what happens when a non-AP MLD changes its group, maybe after receiving an EDP Epoch Request frame. In my understanding, the EDP Epoch Response frame should be received well in advance so that the non-AP MLD is able to compute all its FA parameters. Then it will wait until the time of the next epoch change and apply them. first question
is what happens if the response frame arrives so that the non-AP MLD does not have time to change its parameters? it aborts? disassociate? I have also noticed that the calculation of the FA parameters, which is the following: [PH] According to current definition: yes. [SBA] I currently have some comments to solve regarding this definition. “n” is a poor solution that have been put in place as a compromise but that shows evident drawbacks. So if we have one user in EDP epoch 1 with relative number 10, which has been there during epoch with relative number 9, and changes to a new epoch group 2 which next relative epoch number is 7, in two epochs (relative epoch number 9) its
EDP FA block in epoch group 2 will be the same as in the epoch group 1, relative number 9. Is my interpretation correct? [PH] According to current definition: I believe so. [SBA] I agree and this is not acceptable. is this what we want? [PH] No! As you point out, this can result in an epoch deriving an EDP FA block identical to the EDP FA block of an earlier epoch of
another epoch group, which will be easily detectable since all affiliated STAs of all non-AP MLDs will using identical MAC addresses in both epochs. There are two changes help avoid such scenarios: 1. In the place of (n) in the KDF context, use EpochTSFStartTime(n) or PlannedTSFStartTime(n) (defined in 10.71.2.4 EDP Epoch Start Time Computation)). This was the original proposal for generation
of EDP FA block. 2. Include the EDP Group ID (defined in (9.4.1.84 EDP Epoch Settings field)) in the KDF context One or both of these changes could be applied. [SBA] My preference would be [1] since today we have no rule for the Group ID assignment, and the reuse of a previously used group ID for a same station would end up with the same sequence of MAC addresses for
a given STA. We just need to be sure the computation of those times are performed on the link used for EDP setup. This is the content of the resolution I am preparing for this issue. To unsubscribe from the STDS-802-11-TGBI list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1 To unsubscribe from the STDS-802-11-TGBI list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1 |