Actually, with 802.15.4 Layer 1 fragmenting, the source device sends the destination device a message containing the Fragment Sequence Context Description which includes (among other information) the source and destination addresses and a 6-bit transaction identifier which uniquely defines this fragment sequence. The destination device must ACK this message before the fragment sequence starts. After that ACK, the source sends the fragments that include the transaction identifier but not the source and destination addresses. Any device receiving a fragment checks to see if the transaction identifier belongs to that device, if it doesn’t, the fragment is discarded. In summary, multiple fragment sequences will not get mixed up since the Fragment Sequence Context Description maps the transaction identifier to the source and destination addresses.
Pat On 6, Apr2017, at 10:05, Tero Kivinen <[email protected]> wrote: PWK writes: > Tero makes some good points but perhaps I have a different view on the Layer 1 > fragmentation introduced with 802.15.4k. > > Firstly, the Layer 1 fragmentation was early on intended to be a general > function that could be used with any PHY, that was why it was in the MAC > section for 802.15.4k. During the 802.15.4-2015 revision effort we saw that > there were some PHYs that would require additional effort on the mechanism (I > cannot remember the specifics). Like all other PHYs, as the LECIM PHY assumes that you know who is talking based on the frequency they are using, thus the fragments do not have addressing information in them. There is only two octet fragment header having 7-bit transaction ID and fragment number. If there are multiple senders sending fragments at the same time, they will get mixed up unless you can know it from somewhere else who is sending that fragment. With TSCH it could be possible to use it as if you use dedicated slot, then you know who is sending the frame. With normal 2.4GHz non-TSCH frame this is not really going to happen, as if there is multiple senders sending fragments at the same time, they will get mixed up. If you are using security then you can verify the MIC-32 in the each fragment, and if it does not match, then the fragment was corrupted, or was part of some other fragment transaction... > Rather than delay the revision further we chose the expedient way to > move on which was to put it into the LECIM section, since they were > the PHYs (DSSS in particular) that absolutely needed Layer 1 > fragmentation. In the next revision I will propose that, once again, > we revisit the concept of extending the Layer 1 fragmentation to > more PHYs as well as change the moniker LECIM to LPWAN. The problem there is that max frame size in LECIM is so small that you cannot include the things like source and destination addresses in each fragment, and leaving them out will cause issues on other PHYs, like normal 2.4GHz PHY, especially if there is lots of fragmented traffic. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
