Hi Thomas and Tero,

Thank you for your responses! Yes, Tero's answered my question!!

To summarize:

[For TX]

- Any destination address is accepted in a cell if and only if its
  macNodeAddress is the broadcast address (or the short broadcast
  address).

- A unicast frame is sent over a cell whose macNodeAddress matches its
  destination address or is the broadcast address.

[For RX]

- macNodeAddress has nothing to do with RX.

- Any frame, regardless of the combination of its source and
  destination address, can be received through a cell.

In this sense, the purpose of macNodeAddress is only to make something
like a priority cell for outgoing frames to a certain MAC address
other than the broadcast address. And, we cannot allocate a cell
exclusively used for sending broadcast frames. I wish IEEE
802.15.4-2015 could elaborate what is expected to do with
macNodeAddress... Everybody may have no confusion about these things
except me...

With regard to Link Options or Cell Options, I believe I have the same
understanding as Tero's. I'm relieved here. :-) But, I have one thing
I want to confirm about this.

If a cell is "shared", this means that there is a possibility of
contention or collision as you mentioned. This attribute, shared or
not, is orthogonal to which type of communication, unicast and/or
broadcast, to be done, isn't it?

Therefore, in theory, we may have a dedicated (non-shared) TX cell
whose macNodeAddress is the broadcast address. In this case, a node
having such a TX cell is supposed to be the unique sender in its
neighborhood. We may also have a shared TX cell whose macNodeAddress
is a unicast address. In this case, more than one pairs of devices
could share such a cell for their communication.

How does that sound...?

Best,
Yatch

On 2016/11/15 5:06, Thomas Watteyne wrote:
Yatch,
Can you confirm Tero has answered your question?
Thomas

On Tue, Nov 15, 2016 at 12:02 PM, Tero Kivinen <kivi...@iki.fi 
<mailto:kivi...@iki.fi>> wrote:

    Yasuyuki Tanaka writes:
    > To my understanding, the scheduled cell in 6tisch-minimal can be used
    > for both of unicast and broadcast. The destination address of a frame
    > to be sent with the cell may have the MAC address of a particular
    > neighbor or the broadcast address.
    >
    > But I'm not sure how we can handle that use case with the MAC Layer
    > defined by IEEE 802.15.4-2015.
    >
    > According to IEEE 802.15.4-2015, each scheduled cell has a node
    > address associated with it, which is called "macNodeAddress" and
    > listed as a TSCH MAC PIB attribute in Table 8-85. By definition, this
    > is "(an) address of neighbor device connected to this link or the
    > broadcast address."  It sounds like we cannot use a single cell for
    > unicast and broadcast at the same time; more generally, a cell cannot
    > be associated with more than one distinct MAC address. This also
    > implies that a node has to know the address of a correspondent
    > beforehand to receive frames from it.

    In 802.15.4-2015 there is 3 bits that affect this. TxLink, RxLink and
    SharedLink. SharedLink means that the link is used by multiple senders
    at the same time, and senders need to use different retransmission
    mechanims on the link, as there might be collisions. If the link is
    not SharedLink, it is dedicated link, thus node can send to it without
    caring about collsions. SharedLink only has real mening on the
    TxLinks.

    In addition to that the TxLink might either have one mac address
    assigned to it, or it might be breadcast address. This affects whether
    this node can be used to send to that node. I.e. if node is trying to
    send node xxx, it can either wait for TxLink having macNodeAddress of
    xxx, or it can wait TxLink having macNodeAddress of broadcast.

    macNodeAddress does not really have any meaning for the RxLinks
    (unless they also have TxLinks). There is nothing in the 802.15.4-2015
    which says how macNodeAddress is for RxLinks (i.e., the section 6.7.2
    does not have any filter rules based on that.

    > I thought there might be a special MAC address for internal use which
    > matches any address, like 0.0.0.0 or ::/0, and we could set the
    > address to "macNodeAddress." However, I cannot find such an address...
    >
    > In practice, is the broadcast address used for "any" as well as for
    > "broadcast"? Do you have any thoughts?

    Yes, I think you can use broadcast for NodeAddress for RxLinks.
    --
    kivi...@iki.fi <mailto:kivi...@iki.fi>

    _______________________________________________
    6tisch mailing list
    6tisch@ietf.org <mailto:6tisch@ietf.org>
    https://www.ietf.org/mailman/listinfo/6tisch 
<https://www.ietf.org/mailman/listinfo/6tisch>




--
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com <http://www.thomaswatteyne.com>
_______________________________________


_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch


_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to