Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
> Mark’s view is that TSF 0 = 0, i.e., the TSF time 0 assuming the TSF starts from 0 when the TDLS link is set up.
Wait, what, no!
I never said the TSF was set to 0 when the TDLS link is set up.
My position is that the TSF is set to 0 when the
BSS starts. I don't think there's a separate TSF for a TDLS link. Thanks, Mark --
Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Thanks Mark for the interchange.
Just to be clear, the point that did separate us is what TFS 0 is. Mark’s view is that TSF 0 = 0, i.e., the TSF time 0 assuming the TSF starts from 0 when the TDLS link is set up. (I assume that the TSF is initialized for a TDLS link?) Mine was that TSF 0 is the value of the TSF when the schedule is set up but I now think I was wrong. The Offset is 4 octets so 73 minutes. So as long as the Awake time schedule is set
up within 73 minutes of the start of the link then that is OK. I think that is reasonable. So back to the descriptions of Offset and Interval, I can’t see a real problem.
Offset is effectively the TSF value (with 4 octets of 0s) for the first Awake window, and the description is fine, and clear. It should not refer in any way to the Interval.
Assuming that TSF 0 = 0 then.
nth Awake window starts at TSFn = Offset + n * Interval and hence the formula “TSF MOD Interval = Offset” is correct So the only change I might agree to would be:
“The
Offset field is the time in microseconds between TSF time 0 and the start of
See 11.2.3.12 (TDLS peer power save mode).” Graham From: Mark Rison <m.rison@xxxxxxxxxxx>
Following some 1:1 discussions with Graham, what I understand his view to be (and I may of course have misunderstood) is: - TSF0 is the TSF at the start (or end, TBD) of the PPDU containing the TDLS Peer PSM Request frame (note: so this gets updated if the frame is retried) - Then
the awake windows start when the TSF is TSF0 + n*Interval + Offset, n >= 1 I don't think this works, because: - The transmitter of a retried TDLS Peer PSM Request frame doesn't know which attempt the receiver actually received, so the two sides could end up with different ideas of when the awake windows are - Trying to define/determine the start/end of a PPDU is messy because of DSSS sync delays, signal/packet extension, etc. I think my view, which defines the start times of awake windows independently of exactly when TDLS Peer PSM Request frames are transmitted/received, makes more sense. However, at this point we're going to need a straw poll, or at least views from other parties. [For comparison with the underlined above, my view is that the awake windows start when the TSF is n*Interval + Offset,
n >= whatever it has to be to start after the TDLS Peer PSM Response frame.] Thanks, Mark --
Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi Mark, Sorry, you do not convince me :>( For me the descriptions are clear but I do admit the formula presents a problem. However, I think that the framers got it wrong and the formula should be
(TSF – TSF0) MOD Interval = Offset Then everything works. Graham From: Mark Rison <m.rison@xxxxxxxxxxx>
Thanks, Graham. My responses in blue. CID 3503 says in relation to 1064.20: "The Offset field is the time in microseconds between TSF 0 and the start of a first Awake Window. GS –I think the ‘formula’ is misleading, but actually correct and compatible. The “Offset” clearly is only appropriate for the “first Awake Window”. Subsequent Awake windows then occur, spaced at “Interval”.
I do not think the Offset can be the time of the first AW. If it were so, then you wouldn't be able to set up TDLS peer PSM 2**32 microseconds == about an hour after the BSS had started. The formula is simply saying that the regular Awake Windows are spaced at Interval, and the remainder is the Offset (i.e., the Offset is not equal to the Interval, or a multiple of it).
Hence, the two are compatible but the formula, although correct, is maybe a horrible way of describing it. I would suggest the formula is deleted and maybe something along the lines of
“After the first Awake window, subsequent
Awake Windows begin at TSF values that are separated by Interval time.”
and CID 3502 says: "The Offset field is the time in microseconds between TSF 0 and the start of a first Awake Window. and suggests: Change the first cited text to "The Offset field is the time in microseconds between intervals specified by the Interval field, starting at TSF 0, and the start of the Awake
Window, in microseconds." GS – I don’t like this. I do not think that Offset and Interval are related at all. Maybe the confusion is on TSF 0? What exactly is that? It seems to be a TSF value at time zero. So I don’t think it starts
at the beginning of the TSF field, but at the end of it? I personally would leave this alone. As discussed above, the Offset cannot be the time of the first AW, because it's too small. I think it works like this (picking easy numbers): - Say the Interval is 10000 us, the Offset is 4000 us and the TSF is currently 100500 us (when we decide to do TDLS peer PSM) - The Interval being 10000 us and the Offset being 4000 us means that we potentially have AWs starting at n * 10000 + 4000, n >= 0 - If the TSF is currently 100500 us then the first AW will start at TSF 104000 us (n = 10), then the next one at 114000 us (n = 11), etc. Note this satisfies "Awake Windows begin at TSF values that satisfy the equation TSF
mod Interval = Offset." from 2390.60. Please speak up if you have any questions or comments. Thanks, Mark --
Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk
To unsubscribe from the STDS-802-11-TGM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 |