Xavier Vilajosana writes: > 4) minimal defines when EBs are sent and what information from the wide set of > options (IEs) provided by 15.4 TSCH is sent in an EB.
I.e. provides profile for 15.4 to be used in 6tisch. > 5) it defines the specific 15.4 header settings so 2 nodes can talk together > and establish an initial configuration without discarding frames from one and > another. Again profiling. > 6) it defines the number of security keys that are needed. The actual keys do not belong to this document. If you are trying to say that this document profiles 802.15.4 security by telling that we use two different key, one for the EBs and one for the rest of the data, then this is again profiling. On the other hand it does not provide the information how those two keys are identified, i.e which key id mode and key index are used for K1 and K2. It does give example using Key Identification Mode of 0x01, but there is no text explaining how device knows what KeyIndex is used for K1 and K2. > 7) it defines how the routing information is used to hint the network > structure. That is, how the join priority is used to match the routing > topology. Btw, the join priority field in the TSCH Synchronization IE was renamed to Join Metric in the 802.15.4 revision. This is because term priority is also used for priority traffic etc, thus using it here too caused confusion. And also the join metric is not really a priority, it specifies how far the node sending EBs are from the root, i.e. node sending EBs is setting join metric to be its parent join metric + 1. > 8) it defines the default number, default slot-offset, channel offset of the > cells in the schedule of all nodes in a 6tisch network so the network can be > easily initiated. It also defines the default timing of the slots and the > default slotframe length, etc.. It does not however specify are those numbers fixed for the duration of the network. I.e. can any of those change? It is clear that some of them cannot be changed without tearing down the network (timeslot timing, channel hopping sequence), but what about the number of timeslots in the slotframe, or the number of scheduled cells, or parameters of those cells. > Without that, 2 vendors can be running 15.4e but chances are that they do not > interoperate. The ETSI/6TiSCH plugtest event corroborated the need of such > specification so vendors are able to easily interoperate. This is true, but that is just the reason I think this document is more of an profile than a standard. I.e. if gives defaults, limits some features away, specifies how things are set up etc, so we can have interoperability. There is nothing there that is not already specified in the 802.15.4-2015, it is just profiling the use of it. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
