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?
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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
>
>