Hi Tero, what is the difference between what you propose in the new version
"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)." and using macImplicitBroadcast? According to 15.4e (2012) macImplicitBroadcast (default=false) "Indicates whether frames without a destination PAN ID or destination address are to treated as though they are addressed to the broadcast PANID (0xffff) and broadcast short address (0xfffff)" Does this mean that if Dst Address and Dst PANID are elided we need macImplicitBroadcast set to TRUE in order to be able to identify the frame? I assume (for minimal) we want to stay in most of the default values. Therefore, macImplicitBroadcast set to FALSE, and dst address (short) and dst PANID to be explicit (0xffff). As a second point: Would the use of macImplicitBroadcast change in the new version? thanks! Xavi 2015-09-10 13:38 GMT+02:00 Tero Kivinen <[email protected]>: > 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 >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
