Subject: [6tsch] TSCH: info for each(?) link in Enhanced Beacon frames

From: Pieter De Mil <[email-masked]>
Date: Tue, 30 Apr 2013 10:17:51 +0200

Hi,

I'm implementing 802.15.4e TSCH.

I'm wondering if I should add *all* my active links in an enhanced 
beacon (EB)

Well, for >20 active links, it's not possible to add them all (with the 
127-byte MTU), so I now assume that it's not the goal to add all the 
active links in the EB.

"The TSCH Slotframe and Link IE is used to construct enhanced beacons 
that allow new devices to synchronize to a TSCH PAN."
So, the EB only has to contain the minimum information so that new 
devices can synchronize and join a TSCH PAN?

"The Link Options field indicates whether this link is a TX link, an RX 
link, or a SHARED TX link, and
whether the device to which it is being linked is to be used for clock 
synchronization. The field corresponds
to the Link Options field in the link table for the receiving device."
So, a device sending enhanced beacons, with an RX link advertised, means 
that a joining device should set this as an RX slot?

Well, it makes sense but "Link Information for each Link" in Figure 48gg 
(IEEE802.15.4e standard) is/was a bit confusing..

Thoughts?

Best,
Pieter

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 30 Apr 2013 20:19:42 -0700

My reading of the standard is that the EB contains just enough information
for the new mote to join the network. Of course, what this exactly is
depends on the application.

In the context of 6TSCH, this could be:
- a set of (shared) links in the best effort case. This could, in fact, be
the final set the mote gets, i.e. all motes communicate on a number of
shared links in a "slotted Aloha" fashion. This has the merit of being
extremely simple (e.g. for interop), but does not allow for much
optimization.
- a set of links to contact the neighbor which sends the EB. This can be
used in the distributed cases as a bootstrap for a distributed reservation
protocol.
- a set of links to contact the PCE through the neighbor which sends the
EB. This can be used in the centralize case: the neighbor serves as a
temporary proxy until the PCE has decided what to do with that new mote
(possibly installing more links).

Fantastic to hear that you're implementing TSCH. What platform are you
using?

We should for sure coordinate with the OpenWSN team to ensure
interoperability directly from the start. The easiest is probably to start
with schedule "slotted Aloha" schedule shown in
https://openwsn.atlassian.net/wiki/display/OW/Schedules.

Thomas

On Tue, Apr 30, 2013 at 1:17 AM, Pieter De Mil <[email-masked]> wrote:

> **
> I'm wondering if I should add *all* my active links in an enhanced beacon
> (EB)
>
> 127-byte MTU), so I now assume that it's not the goal to add all the active
> links in the EB.
>
>
> "The TSCH Slotframe and Link IE is used to construct enhanced beacons that
> allow new devices to synchronize to a TSCH PAN."
> So, the EB only has to contain the minimum information so that new devices
> can synchronize and join a TSCH PAN?
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>