Tero is correct that there are errors in Table 2a from 802.15.4e-2012 -
things in the table inconcistentet with text and clearly not intended.
This is what the revision team is trying to fix. Input from implementers
and users will help ensure we "fix" it instead of just breaking it
differently.
BR
Ben
On 7/7/2015 4:06 AM, Tero Kivinen wrote:
Benjamin A. Rolfe writes:
There is certainly no intent, at least with any of the documents I
have posted regarding PAN ID compression, to change behaviors as
understood by those using 802.15.4e as published, the intention is
to clear up ambiguity in amendment and correct obvious errors (like
the inclusion of MP-frames in the PAN ID compression table, which
makes no sense)
Yes. Luckily the MP-frames do not even have PAN ID compression field,
only the PAN ID Present flag, and source PAN ID always matches the
destination PAN ID...
Listing MP-frames in that table did confuse me originally...
We received comments from people who could not unambiguously
determine what to implement given the text published in 2012. It is
therefore our job to "fix" the text so that it can be implemented
consistently. There were also several errors introduced WRT the
"legacy" behavior (frame version < 2) which were not intended by
TG4e, such as losing the text which specified that PAN ID
compression is only used when the source and destination PAN IDs are
equal.
Reading table 2a in 802.15.4e indicates that there is no way to send
following frame:
* Has IEs, i.e. requires 0b10 frame format
* Has source address and source PAN ID
* Has destination address and destination PAN ID
* And those source and destination PAN IDs are not same
I.e. you cannot anymore send frames using 0b10 frame format from one
PAN to another... This is possible with frame format 0b00 or 0b01, but
if you want to use IEs or anything that requires 0b10 frame format,
then you are out of luck.
In your 15-15-0130-03 document you changed this to be possible by
changeing "short or extened" / "short or extened" / "0" (PAN ID
compression) / "Beacon, Data, Acknowledgement, Command", so that it
says "Present" / "Present" instead of "Not Present" / "Present" in PN
ID columns.
So I assume this was one of those unambiguities you mentioned there?
The point of querying implementers and developers of other
specifications based upon the published standard is to resolve
ambiguities in a rational and realistic way. It would be of great
help to the revision task if you can clarify what "following the
information from Table 2a" means specifically.
Yes...
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
