Xavier Vilajosana writes: > >>>>>>>>>>>>>>>>> > > The last topic has to do with the periodic beacon addressing format. > Following the standard ieee802.15.4e-2012, point 5.1.6.2 “Reception and > rejection”: “…If a destination PAN identifier is included in the frame, it > shall match *macPANId *or shall be the broadcast PAN identifier…” > > Having a not associated mote, which does not have macPanId yet, would not > be able to filter correctly the periodic beacon transmitted by a > (PAN)Coordinator, which follows draft-ietf-6tisch-minimal-11.
During the SC-M process there was issue raised in the filtering rules while doing scanning. The current text in 802.15.4 is bit confusing, and does not really work, but when this was asked from the vendors, they said that nobody implements it as specified in the draft. I.e. the current process is supposed to be store the macPanId, set it to 0xffff, do scan, restore macPanId. I think the current proposal will be more like what implementations actually do, i.e. they have special flag which says they are doing a scan, and they will then accept all beacons, but no other frames or something like that (this change will be in the next revision of the draft, so I have not yet read the final text). Anyways, there is no point of include destination pan id in the beacon anyways, so leaving it out is better. > We propose the use of the next combination for a periodic beacon in a TSCH > network (following table 2a in [IEEE802154-2012]): > > - Sequence Number: Not Present (not necessary). > > - Destination PANID: Not Present. > > - Destination Address: Not Present. > > - Source PANID: Present. > > - Source Address: Present (Short mode). > > >>>>>>>>>>>>>>>>>> > > My proposal here is something in the middle. (We want Sequence > Numbers to match packet and ack). We want long addresses to avoid a > Short->Long address mapping service in minimal. > > The PAN ID Compression bit in a BEACON frame MUST indicate that the > Source PAN ID is "Present" and the Destination PAN ID is "Not > Present". The source and destination address fields MUST be filled > with an extended address (64 bit) and this be indicated in the > corresponding Frame Control field. Above you marked destination address as not present, and here you say it will be extended address. Is there any reason to use extended address as destination address for the beacon? It is normally sent to the broadcast address? Do we assume that minimal uses macImplicitBroadcast set to TRUE or FALSE? -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
