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, Pascal -----Original Message----- From: 6tisch [mailto:[email protected]] On Behalf Of Michael Richardson Sent: mardi 8 août 2017 19:41 To: [email protected] 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 <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
