Unsure what your question is, Michael.

The node that is scheduled to overhear can see the cell as shared, to it will 
not ack.
There is the problem of the dMAC. In 6TiSCH tracks we set it to broadcast. But 
this is not really a broadcast since only the intended nodes are scheduled to 
wake up and listen to that cell. So the GMPLS properties of the cell turn it in 
a multicast group, the mcast group of nodes selected by routing as being 
progress towards the destination from the point of view of the sender.

Note that ISA100.11a has a concept of Duocast, whereby the MAC layer of the 
sender expects 2 acks and is happy if one comes. The first ack is aligned to 
the end of the frame whereas the second if aligned to the end of the time slot.

There is no 'hardware' per se, since unless I miss something, all this is upper 
MAC, classically software. So anyone shuld be able to try it on its preferred 
gear. We used OpenMotes.

Take care,


-----Original Message-----
From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Michael Richardson
Sent: mardi 8 août 2017 19:41
To: 6tisch@ietf.org
Subject: [6tisch] 6tisch-pre-reqs-00 <- can it be implemented??

<#part sign=pgpmime>

I was reading draft-papadopoulos-6tisch-pre-reqs-00, and I came across:

   Considering that each frame may be transmitted
   twice in unicast to each parent, then depending the transmission,
   either DP will acknowledge the frame or AP will.

I think the possibilities of this are amazing, but I wonder if this will 
realistically work with many pieces of hardware.

Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works  -= IPv6 
IoT consulting =-

6tisch mailing list

6tisch mailing list

Reply via email to