Re: [6tisch] 6top-interface-04

[Tero Kivinen <[e-mail]>]

Qin Wang writes:
> You raised a good question, i.e. how to define a cell for broadcast in 6top.
> 
> (1) I think 6top needs a way to define broadcast cell.

Yes. The higher layer protocol trasmitting the real schedule to the
devices will need a way to tell that this cell is broadcast cell. 

> A sender can not assume or know if the message transmitted in a TX
> cell will be received by all other nodes even if its nodeAddr is set
> to oxffff, because sender cannot know others TSCH schedule. Thus,
> there must be some bitmap in the sender to tell TSCH scheduler
> whether the TX cell is a Unicast cell or Broardcast Cell, i.e.
> neighbors are listening or not sure.

I do not think this is true. If the PAN coordinator (or whoever is
giving out schedule information) sends information (over 6top or some
other protocol) to device configuring cell for broadcast traffic, then
the device will fill in the link information with nodeAddr of 0xffff,
and can use that cell for broadcast traffic.

It is true, that the device cannot know if the PAN coordinator hsa set
up schedule so that not everybody is listening that broadcast cell,
but for his point of view that cell is for broadcast traffic, and he
can use it for that, and he should be listening it for broadcast
transmissions.

The PAN coordinator will then take care of giving schedule out in
consistent way, i.e. if that cell is supposed to be broadcast traffic
for everybody, he needs to give that information to everybody.

I.e. for the devices point of view it is enough to have link that is
for TX, SHARED, and RX with nodeAddr of 0xffff, and for him this is
broadcast cell.

> (2) It is indeed that IEEE80.15.4e uses LinkType to indicate if the cell is
> for Advertisement, but does not say it cannot be used to broadcast other
> message as you said. Thus, I wonder if 6top, as a sublayer, can take advantage
> of LinkType to define the broadcast cell, and let the content of broadcast
> come from broadcast Queue, EB or other broadcast message.

I do not think there is any need to redefine what ADVERTISING means.
It has clear meaning already and it is releated to the beacons, not
broadcasts. Yes, beacons are quite often broadcast packets, but
beacons can also be sent on links, which only the coordinator is
transmitting, and everybody else is only listening.

For real broadcast link you would need to be set up so that everybody
will listen, and everybody can also send.

> On Wednesday, September 30, 2015 2:16 PM, Tero Kivinen <[e-mail]> wrote:
> 
> Qin Wang writes:
> > In the IEEE802.15.4e, there are two attributes related with a cell, i.e.
> > LinkOption and LinkType. LinkOption indicates TX, RX, Shared, or
> Timekeeping;
> > and LinkType indicates Normal or Advertising. According to my understanding,
> > if the attributes of a cell are set as LinkOption = TX and LinkType=
> > ADVERTISING, then the cell can be used as Broadcast cell. Make sense?
> 
> LinkType of ADVERTISING means that this link is used to send enhanced
> beacons out. There can be other broadcast traffic going out than
> enhanced beacons, so I do not think you can only claim that
> ADVERTISING links are broadcast cells.
> 
>     ADVERTISING = 1, and indicates the link may be used to send an
>     Enhanced beacon.
> 
> and
> 
>     ADVERTISE links may be used to send Enhanced beacons as the
>     result of the MAC receiving a MLME-BEACON.request.
> 
> I would assume that broadcast link is something that is defined so
> that all devices are listening that, i.e. where the listeners have RX
> bit on, and nodeAddr for the sender is set to 0xffff. I do not think
> linkType has anything to do with that, but as 6top-interface-04 does
> not define what broadcast link/cell means, it is impossible to say.
-- 
[e-mail]