Hi Remy, this is a concurrent situation so both should happen almost at the same time. The return code to 6N2 is BUSY.
regards, X 2017-06-19 16:37 GMT+02:00 Remy Leone <[email protected]>: > Hello, > > I got a question about 6P04: > > obj: Check that concurrent transaction cannot request for the same cells > in the schedule according to draft-ietf-6tisch-6top-protocol-05 > cfg: star > ref: IEEE802.15.4-2015, draft-ietf-6tisch-6top-protocol-05 > pre: > - The DAGroot sends EBs periodically, with a fast rate (equal to 10 > sec, according to IEEE802.15.4std), so that the 6N does not need to send > KAs for keeping synchronization. > - All EB packets are sent on a single frequency. > - Power on DAGroot. > - Wait until all 6N join the DAGroot > seq: > - s: > - The 6N1 sends a 6P ADD request to the DAGroot for 2 slots. > - The candidate list is {4,5}. > - s: > - The 6N2 sends a 6P ADD request to the DAGroot for 2 slots. > - The candidate list is {4,5}. > - c: > - Check that the returned code for the operation is BUSY. > > Should we add more details about the timing? Because the check step seems > very imprecise. Is it the 6N2 that get the busy return code? The 6N1? Do we > have answers each time a request is sent? > > Best regards > > Rémy > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > -- Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 [email protected] <[email protected]> http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya]
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
