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
