Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGM] 11me/D2.0 CID 3502/3503 (Offset field in TDLS peer PSM)



--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

<My position is that the TSF is set to 0 when the BSS starts>

 

Sorry I got that wrong.  Then there is a problem as we need a starting time – again, what is TSF 0? clearly it cannot be TSF = 0 as 4 octets for Offset is not enough.

 

I think it is time Menzo stepped in to put us out of misery and tell us what the intention really was.

 

Graham

 

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Thursday, December 8, 2022 11:25 AM
To: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: 11me/D2.0 CID 3502/3503 (Offset field in TDLS peer PSM)

 

> 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>
Sent: Thursday, 8 December 2022 16:09
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: 11me/D2.0 CID 3502/3503 (Offset field in TDLS peer PSM)

 

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 a the first Awake Window.

See 11.2.3.12 (TDLS peer power save mode).

 

 

Graham

 

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Wednesday, December 7, 2022 5:51 PM
To: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: 11me/D2.0 CID 3502/3503 (Offset field in TDLS peer PSM)

 

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>
Sent: Wednesday, 7 December 2022 14:46
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] 11me/D2.0 CID 3502/3503 (Offset field in TDLS peer PSM)

 

--- 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>
Sent: Tuesday, December 6, 2022 5:44 PM
To: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Cc: 'mwentink@xxxxxxxxxxxxxxxx' <mwentink@xxxxxxxxxxxxxxxx>
Subject: RE: 11me/D2.0 CID 3502/3503 (Offset field in TDLS peer PSM)

 

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.
See 11.2.3.12 (TDLS peer power save mode). " -- doesn't seem compatible with "Awake Windows begin at TSF values that satisfy the equation TSF mod Interval = Offset." at 2390.60

 

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.
See 11.2.3.12 (TDLS peer power save mode). " -- but the TSF is 8 octets and the Offset field is only 4 octets

 

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