Subject: [6tisch] 6TiSCH Plugtest - Golden Image - Addressing fields.

From: Tero Kivinen <[email-masked]>
Date: Wed, 1 Jul 2015 15:44:50 +0300

José Ángel Miranda writes:
> We have tried the golden image and while we were looking at both enhanced
> beacon and data frames, we have seen a strange addressing field
> combination:

The PAN ID compression in the 4e is mess. The table there does not
provide proper information to be able to implement it. We did notice
this while doing the 802.15.4rev work and are now trying to fix this
in next version.

When asking about this from people who were there when 4e was done
they said that the last line of that table should actually be so that
it has separate entries for short and extended address formats, not
only whether addresses are present or not.

The 2nd last line saying:

Src 	Dst  	Frame	Frame	Src	Dst		PAN
addr	addr	Ver	Type	PAN	PAN		ID
		  		ID	ID		Compr.

Present	Present	0b10	B, D,	Not	Present		0
			A, C	Present

Is also wrong, as if PAN ID compression is not set, then both PAN IDs
should be there. I.e. it should be:

Src 	Dst  	Frame	Frame	Src	Dst		PAN
addr	addr	Ver	Type	PAN	PAN		ID
		  		ID	ID		Compr.

Present	Present	0b10	B, D,	Present	Present		0
			A, C

I.e. if we do not have PAN ID compression set to 1, then we always
have 2 PAN IDs.

--

The last line should be spit as follows

Src 	Dst  	Frame	Frame	Src	Dst		PAN
addr	addr	Ver	Type	PAN	PAN		ID
		  		ID	ID		Compr.

Short	Short	0b10	B, D,	Not	Present		1
			A, C	Present

Short	Ext.	0b10	B, D,	Not	Present		1
			A, C	Present

Ext	Short	0b10	B, D,	Not	Present		1
			A, C	Present

Ext	Ext	0b10	B, D,	Not	Not		1
			A, C	Present	Present

I.e. both PAN IDs should not be present only and only if both source
and destination addresses are extended addresses and PAN ID
Compression bit is set to 1.

If either of the addresses is short address, then we still need PAN
ID, thus we cannot completely omit it, but if the PAN IDs for source
and destination are same, we can compress them to be one by setting
PAN ID compression bit.

The new version of the table is described in 15-15-0130-03 document

https://mentor.ieee.org/802.15/dcn/15/15-15-0130-03-0mag-proposed-pan-id-compression-table.docx

> - Data frame ( from GD-1.0.0 ):
> 
> 5F | 41EA | 00 | FECA | FFFF | 1C9F0D06004B1200 | 00FE |
> 7C0040BBBB00000000000000124B00060D9F1CFF020000000000000000000000000002EE7A133A00124B00060D9F1C9B01558000000000B8330000BBBB00000000000000124B00060D9F1C
> 
> - FCF        : 41EA
>  |-> PAN ID Compression = b1
>  |-> Dst Addr Mode      = b10 (short)
>  |-> Frame Version      = b10
>  |-> Dst Addr Mode      = b11 (extended)
       ^^^

I assume that was supposed to be Src Addr mode?

> 
> - Dst PANID           : FECA
> 
> Therefore, if you check the table 2a ( 5.2.1.1.5 -- IEEE802.15.4e - 2012 ),
> you can check that this combination is not present.

But it is present in the new table version which will be in the next
revision, and that it matches the 2nd last line in the new table. 

> There could be two
> different options in order to solve this for the frame version 0b10:
> 1. Taking the last row of the table: Src Address and Dst Address are present,
> PANID Compression is set, thus -->Src and Dst PANID are not present.
> 2. Taking the last but one row: Src Address and Dst Address are present, Src
> PANID is not present, Dst PANID is present, thus --> PANID Compression is not
> set.
> 
> For the beacon frame is the same situation.
-- 
[email-masked]