Ralph Droms writes:
The EB_PERIOD determines the join time and impacts energy consumption. The
value is a trade-off of this two elements according to the network
administrator, as shorter the EB period more energy is used but sooner the
nodes join the network. This number does not affect different vendor nodes
aiming to join the same network (in terms of inter-operability). For us
this is more a network policy, IMHO defining a default value would not fit
most of the cases.
Is it necessary for all devices in a network to use the same value EB_PERIOD?
Not really. The device wanting to join the network needs to listen to
each channel for certain time period to find enhanced beacons. The
needed depends on the EB_PERIOD, slotframe size, timeslot length and
number of channels.
As it cannot know any of those parameters it needs to guess values for
all of those, and use them, and if it does not hear any beacons during
the timeout period calculated based those guessed values, it can
assume that there is no network nearby, and go for extended sleep
waiting for network to appear.
If the typical values like timeslot length = 10ms, slotframe size =
101, number of channels = 16 and EB_PERIOD of 3 is used, then it knows
that:
- Slot frame takes 10ms * 101 = 1.01 seconds.
- Beacon is sent every 3rd slot frame so every 3.03 seconds.
- Beacon is sent on random channel out of 16, so but most likely
different channel for every time, so if it waits for one channel
for 16*3.03 seconds = 48.48 seconds it should have seen one beacon
on that channel
- After that timeout it can move to the next channel, as it might be
that not all 16 channels are in use, so it needs to listen other
channels too, testing all 16 channels takes 16 * 48.48 seconds =
775.68 seconds == abour 13 minutes.
So after 13 minutes it can assume that there is no network and go to
sleep. If EB_PERIOD is 10 then it needs to wait for 43 minutes...
On the other hand in most cases all channels are in use, and it will
find the beacon after 25 seconds or so on average with EB_PERIOD set
to 3, and 80 seconds if EB_PERIOD is 10...
This assumes that network has good parameters, i.e. if the slotframe
size would be 100, and number of channels 10, then beacons would
always end up on the same channel, and if that channel happened to be
the last one scanned it can take long time to find out that channel.
Also if that one channel ends up having issues, then beacons might be
lost completely.
Btw, all of the above do assume that none of the beacons are ever
lost, so in practice the device needs to wait for 2-3 times the
EB_PERIOD * slotframe size * timeslot length * number of channels
before moving to next channel, or it might repeat the process 2-3
times before giving up. On the other hand tsch is quite chatty
anyways, so the device should see at least some packets go over the
air during the scan, and if it does not hear any radio transmissions
during the scan it might skip to next channel must faster.
If so, how is that value communicated or configured in all devices?
It is not communicated, and devices do not need to agree on value.
--
kivinen(_at_)iki(_dot_)fi