Xavi Vilajosana Guillen writes: > 4.5.1: > 1) What is the EB source address size? Presumably the dst is short FFFF, > but it isn't stated. > > XV: According to 15.4 -2015 > page 65.
Which version of 802.15.4-2015 you have as the page 65 does not match anything what you are saying. Page 65 has figure 6-6 about TSCH Retransmission backoff. Better make sure you have the correct version, and download it from http://standards.ieee.org/getieee802/download/802.15.4-2015.pdf > 2) "While listening for EBs, a joining node set its own PAN ID to > 0xffff..." Why is the PAN ID set to FFFF? This implies that the EB either > doesn't have a dst PAN ID (contrary to the previous paragraph) or that > nodes accept EB's from any advertising PAN, which makes PANID not useful > in partitioning networks. > > XV: This comes from some discussions we had some time back. I will try to find > the threads. As far as I remember, the concern was that the PAN ID is not > known by the node performing the scan. Then in order to be able to accept the > EB following the filtering rules (level 3) defined in the 15.4-2011. section > 5.1.6.2 or later in section 6.7.2 of 15.4-2015 the PAN ID has to be set to > FFFF. I agree with you that we need to check this again. The text "set its own PAN ID to 0xffff" is old text that should not be here in minimal anymore. The 802.15.4-2011 section 5.1.2.1.2 did that to get past the receive filters, but this had some other issues, and this text was removed in 802.15.4-2015 and the issue was solved properly. In 802.15.4-2015 the issue was fixed so that the section 6.7.2 Reception and rejection has special text saying that filtering is not done based on normal filtering rules if we are doing scanning, but instead the MAC layer will process frames are described in the relevant subclause of 6.3.1... > 4.5.2: "EBs SHOULD NOT be used for time synchronization." The JN must > initially set it's clock from the EB, otherwise it will have no idea when > to send in its join request - see 6.2. I think you mean that EB's should > not be used for time synchronization after a node has K2? > > XV: I agree. We need first to join the network. I will correct that. Actually whether the node has K2 or not, is not relevant, the fact whether it has any other time keeping neighbors tells whether it can use any other method than EBs for time synchronization: See section 6.5.4 Synchronization in TSCH PAN: Note that a device sending Enhanced Beacons to advertise a TSCH PAN should set the Timekeeping bit in the Link Option field, as described in 7.4.4.3, for the joining devices’ receive link so that joining devices can maintain time synchronization until additional time source neighbors are configured by a higher layer. Note, that there is two levels of timekeeping, first is the very course level i.e., getting the ASN, and then time synchronization inside the slot. The nodes get the ASN when they join the network and they gain that from the EB. This is not really relevant here (except that it forces the EBs to be unencrypted, even when they can be authenticated as joining nodes need to be able to read ASN from the EB). Then the second level of timekeeping, i.e., to keep synchronization inside the slot is what we are talking here. For that the node needs to use two methods described in the 6.5.4.2 Node synchronization. First method is to use acknowledgement-based synchronization, which requires exchanging acked message with time keeping neighbor. Second method is the frame based synchronization, and that requires receiving frame from the time keeping neighbor of the node. The second method can also use EBs, and that would be quite cheap way of keeping in sync with network, as it does not require sending frames too often. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
