Adjusting_tbtt in mesh capability

Adjusting_tbtt in mesh capability

[Neelansh Mittal]

Currently, for a mesh node ,the mac80211 
sync implementation sets the tbtt 
adjustment bit , when it is adjusting it's 
tsf as part of Neighbour offset 
Synchronization(Function:mesh_sync_offset_
adjust_tbtt())
According to ieee80211s specification, 
this bit should(only) be set when tbtt 
adjustment procedure(as part of tbtt 
selection/mbca) is ongoing.
So why does mac80211 set it as part of 
Offset syncronization, ie , what is 
advantage the when a mesh node announces  
that "my tbtt will be delayed" to it's 
peers?

Re: Adjusting_tbtt in mesh capability

[Peter Oh]

On 02/03/2016 12:18 PM, Neelansh Mittal wrote:
> Currently, for a mesh node ,the mac80211
> sync implementation sets the tbtt
> adjustment bit , when it is adjusting it's
> tsf as part of Neighbour offset
> Synchronization(Function:mesh_sync_offset_
> adjust_tbtt())
> According to ieee80211s specification,
> this bit should(only) be set when tbtt
> adjustment procedure(as part of tbtt
> selection/mbca) is ongoing.
> So why does mac80211 set it as part of
> Offset syncronization, ie , what is
> advantage the when a mesh node announces
> that "my tbtt will be delayed" to it's
> peers?
I guess it's to prevent mesh peers from running TBTT adjustment?
Setting TBTT adjustment bit is good idea although the standard is 
addressing TBTT adjustment bit during MBCA/TBTT selection procedure,
since the key idea of setting the bit is to run TBTT adjustment by only 
one mesh point at a time IMO.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Adjusting_tbtt in mesh capability

[Neelansh Mittal]

> I guess it's to prevent mesh peers from running TBTT adjustment?
That's correct.

But in this scenario(Synchronization) , the beacon would be delayed , 
and the peers running faster than me, would see this as drift and should 
delay their TSFs too.(which they would do if the bit is unset)

On the contrary ,If the adjusting_tbtt bit is set, the faster peers 
would ignore this beacon and hence the "drift due to change in TSF". 
Therefore, every time a node adjusts it's TSF, there would be a TBTT 
drift as seen by the faster mesh nodes.This drift would keep on getting 
added(every time a faster node 'delays' it's TSF).

Peter Oh <poh@...> writes:

> 
> 
> On 02/03/2016 12:18 PM, Neelansh Mittal wrote:
> > Currently, for a mesh node ,the mac80211
> > sync implementation sets the tbtt
> > adjustment bit , when it is adjusting it's
> > tsf as part of Neighbour offset
> > Synchronization(Function:mesh_sync_offset_
> > adjust_tbtt())
> > According to ieee80211s specification,
> > this bit should(only) be set when tbtt
> > adjustment procedure(as part of tbtt
> > selection/mbca) is ongoing.
> > So why does mac80211 set it as part of
> > Offset syncronization, ie , what is
> > advantage the when a mesh node announces
> > that "my tbtt will be delayed" to it's
> > peers?
> I guess it's to prevent mesh peers from running TBTT adjustment?
> Setting TBTT adjustment bit is good idea although the standard is 
> addressing TBTT adjustment bit during MBCA/TBTT selection procedure,
> since the key idea of setting the bit is to run TBTT adjustment by 
only 
> one mesh point at a time IMO.
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-
wireless"
> > in
> > the body of a message to majordomo@...
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
wireless" in
> the body of a message to majordomo@...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>