Hi Tero, I realized I am using Draft IEEE P802.15.4-REVc/D01TM Revision of IEEE Std 802.15.4-2011 date 17-03-2016.
so it seems a draft of the final 15.4. I switch to the last one. Sorry for the confusion. I will check and follow your comments. Thanks! X 2016-12-16 13:15 GMT+01:00 Tero Kivinen <[email protected]>: > 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] > -- Dr. Xavier Vilajosana Guillén Research Professor Wireless Networks Research Group Internet Interdisciplinary Institute (IN3) Universitat Oberta de Catalunya +34 646 633 681| [email protected] | Skype: xvilajosana http://xvilajosana.org http://wine.rdi.uoc.edu/ Parc Mediterrani de la Tecnologia Av. Carl Friedrich Gauss, 5. Edifici B3 08860 Castelldefels (Barcelona)
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
