Subject: [6tisch] Node Address of Cell

From: Yasuyuki Tanaka <[email-masked]>
Date: Mon, 14 Nov 2016 16:31:15 +0100

Hi all,

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.

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?

Best,
Yatch

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 15 Nov 2016 05:02:53 +0200

> 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.

> "broadcast"? Do you have any thoughts?

Yes, I think you can use broadcast for NodeAddress for RxLinks.
-- 
[email-masked]

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 15 Nov 2016 13:06:51 +0900

Yatch,
Can you confirm Tero has answered your question?
Thomas

On Tue, Nov 15, 2016 at 12:02 PM, Tero Kivinen <[email-masked]> wrote:

> _______________________________________________
> 6tisch mailing list
> [email-masked]
> 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
_______________________________________

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Tue, 15 Nov 2016 12:06:36 +0100

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:
> On Tue, Nov 15, 2016 at 12:02 PM, Tero Kivinen <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Yasuyuki Tanaka writes:
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
>
>
>
>
> --
> www.thomaswatteyne.com <http://www.thomaswatteyne.com>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Nov 2016 05:05:43 +0200

> macNodeAddress... Everybody may have no confusion about these things

We had long discussion about that when 802.15.4-2015 revision was
being made, and we tried to clear things as much as possible, but as
people also had bit different things what 4e meant it was bit hard... 

> broadcast, to be done, isn't it?

Yes. The 802.15.4-2015 [1] CSMA-CA algorithms (section 6.2.5.1) state
machines Figure 6-5 and TSCH CSMA-CA retransmission algorithm (section
6.2.5.3) Figure 6-6 do not make difference whether the slot is
broadcast or not. It just have steps "Wait for next TX link to
destination" and that can be either broadcast link or link only for
it. The shared bit affects the next step which is "Dedicated Link?" /
"Shared slot?" questions.

[1] http://standards.ieee.org/getieee802/download/802.15.4-2015.pdf

> whose macNodeAddress is the broadcast address.

Yes. I.e. you are the only one allowed to send to that link, but there
are multiple listeneres in there. So, as it does not have shared bit
on, there will not be other transmitters, but there can be multiple
listeners on it. 

> 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.

Yes.
-- 
[email-masked]

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Wed, 16 Nov 2016 11:56:01 +0100

Hi Tero,
Thank you for the clear explanation!!

I check Figure 6-5 and Figure 6-6 that you referred. Indeed, there is
no distinction on a sending frame between unicast or broadcast.

Now I've got synchronized. :-)

Best,
Yatch

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 16 Nov 2016 15:08:52 +0000

Synchronized is a good thing in a 6TiSCH world :-)