Subject: Re: [6tisch] comments on 15.4 header fields in minimal

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 7 Sep 2015 05:30:26 +0200

Dear all,

after the last WG webex meeting on Friday we decided to finalize this
discussion and come out with a proposal on the IEEE802.15.4 specific header
fields and what minimal should say about that.

the threads where this is being discussed are:
https://mailarchive.ietf.org/arch/msg/6tisch/2pXzQH7n_6EjvVo05QlOXnzSG3c

and
https://mailarchive.ietf.org/arch/msg/6tisch/9GslRkNZYLECdIWwwU0QqD-XlEI

My proposal is to find a text for minimal that does not restrict the
implementation to any version of 15.4 but instead indicates that the (PANID
Compression bit) is used according to the underlying 15.4 version
implemented.

here a proposal:

"The IEEE802.15.4 header of all frames MUST include the Sequence Number
field, the Source Address field and the Destination Address field and only
the Destination PANID. Frame Version field MUST be set to 0b10 (Frame
Version 2).
When using  DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types 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. The
Destination PANID MUST be present, the Source PANID MUST be elided and the
PANID Compression bit MUST be set or clear according to the specific
IEEE802.15.4 implementation. "

As per Jose (Kirale) email there are several cases where this
implementation would require a special handling of packets when running in
minimal compliant mode. Although this might work, maybe is time to also
make things simple and not force another set of IF cases to support that
mode.

Finally, note that this is for minimal, which is a fallback mode of
operation or used for initial interop testing. This means that this mode of
operation is not the one that will be running in most of the networks all
the time but instead will be switched on when something fails or the
network initializes.

regards,
Xavi

2015-07-27 11:00 GMT+02:00 Robert Cragie <[email-masked]>:

> For some reason, it was deemed necessary to change PAN ID compression in
> 802.15.4-2012 for frame version 2 but there is an issue with the case where:
>
> * both addresses are present
> * either or both is a short address
> * PAN ID compression is set to 1
>
> In this case the inferred PAN ID is 0xffff but it is not possible to
> distinguish an identical short address which may be allocated in different
> PANs. So I believe the decision was to keep the original format for PAN ID
> compression where either or both are short addresses but to change the
> behaviour if both addresses are extended addresses. I have already pointed
> out that this is a significant change from frame version 0/1 and changes
> the meaning for PAN ID compression. See the analysis document I sent out
> earlier.
>
> I don't actually see how 802.15.4e-2012 Table 2a can actually be used as
> it is erroneous as described above. I would be interested to know if anyone
> is doing it this way, especially using PAN ID compression set to 1.
>
> Robert
>
> On 27 July 2015 at 05:52, Xavier Vilajosana <[email-masked]
> > wrote:
>
>> Hi,
>>
>> we discussed this concern at the IETF meeting. In minimal we wanted to
>> support what is already standardized (15.4e-2012) but it seems that if we
>> make things align to 2012 then we won't be compatible with 2015. If we try
>> to make the text less specific aiming to have people use the table they
>> want we loose some how the sense of minimal as different people
>> implementing it will have different configurations (specially PIDC bits
>> set).
>>
>> So, what do we do?
>>
>>
>>
>> 2015-07-26 2:50 GMT+02:00 Jonathan Simon <[email-masked]>:
>>
>>> I noticed I said 15.4-2012 in my previous email.  I meant 15.4e-21012 in
>>> case it wasn't clear.
>>>
>>>
>>> On Sat, Jul 25, 2015 at 11:39 AM, Robert Cragie <
>>> [email-masked]> wrote:
>>>
>>>> I too have some concerns with the way the PAN ID compression is used
>>>> for frame version 2. Please see attached analysis regarding PAN ID
>>>> compression.
>>>>
>>>> Robert
>>>>
>>>> On 24 July 2015 at 21:00, Jonathan Simon <[email-masked]> wrote:
>>>>
>>>>> Pat - I’m noticing some differences between the proposed table and the
>>>>> one in 15.4-2012.
>>>>>
>>>>> In 15.4-2012, the last 2 rows of table 2a are
>>>>>
>>>>> SRC addr   DST addr    SRC PAN          DST PAN         PIDC
>>>>> Present    Present     Not Present      Present         0    (row 12)
>>>>> Present    Present     Not Present      Not Present     1    (row 13)
>>>>>
>>>>> In the proposed table, rows 12-14 correspond to the 2012 row 12 case
>>>>>
>>>>> SRC addr   DST addr    SRC PAN          DST PAN         PIDC
>>>>> Extended   Short       Not Present      Present         1
>>>>> Short      Extended    Not Present      Present         1
>>>>> Short      Short       Not Present      Present         1
>>>>>
>>>>> So the PIDC bit is inverted from the previous version for some address
>>>>> sizes, but for both extended addresses (new table row 7), you keep the
>>>>> original sense:
>>>>>
>>>>> SRC addr   DST addr    SRC PAN          DST PAN         PIDC
>>>>> Extended   Extended    Not Present      Present         1
>>>>>
>>>>> This breaks backward compatibility for older applications that weren’t
>>>>> considering address size.
>>>>>
>>>>> There is no row in the new table that corresponds to 2012 row 13 for
>>>>> mixed or short addresses.  This breaks our existing IP product
>>>>> implementation.
>>>>>
>>>>> --
>>>>> Jonathan
>>>>>
>>>>> On Jul 21, 2015, at 11:26 PM, Pat Kinney <
>>>>> [email-masked]> wrote:
>>>>>
>>>>> As per our 6tisch meeting yesterday concerning the PAN ID compression
>>>>> bit table, I have attached an IEEE 802.15 document showing the changes to
>>>>> the latest revision draft. This document will act as guidance to the
>>>>> Technical Editor to modify the revision draft.  In summary, it was agreed
>>>>> that frames of version numbers “0” or “1" should revert to the instructions
>>>>> stated in IEEE 802.15.4-2011.  For frame version “2", new text will be
>>>>> inserted into the revision declaring the rules in a non-ambiguous fashion.
>>>>>
>>>>> I would ask those interested in setting the header bits to read this
>>>>> document and respond with critiques or questions.
>>>>>
>>>>> Thanks, Pat
>>>>>
>>>>> Pat Kinney
>>>>> *Kinney Consulting LLC*
>>>>> IEEE 802.15 WG vice chair, TG chair
>>>>> ISA100.11a WG chair
>>>>> O: +1.847.960.3715
>>>>> [email-masked]
>>>>>
>>>>> <15-15-0561-03-0mag-yet-another-document-explaining-pan-id-compression
>>>>> (1).docx>
>>>>>
>>>>> On 21, Jul2015, at 12:46, Xavier Vilajosana <
>>>>> [email-masked]> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> From the discussion today, the section mandating the use of certain
>>>>> 2012 specific configuration needs to be changed so we can be independent to
>>>>> the evolution of the 15.4 spec.
>>>>>
>>>>> The current text is:
>>>>>
>>>>> The IEEE802.15.4 header of all frames MUST include the Sequence Number
>>>>> field, the Source Address field and the Destination Address field.
>>>>> In the Frame Control Field, this translates to:
>>>>>
>>>>> the Frame Version field MUST be set to 0b10 (Frame Version 2)
>>>>>
>>>>> the Sequence Number Suppression bit MUST be set to 0b0
>>>>>
>>>>> the Source Addressing Mode MUST set to 0b11 (long address)
>>>>>
>>>>> the Destination Addressing Mode MUST set to 0b11 (long address) except
>>>>> for the broadcast address for which Destination Addressing Mode SHOULD set
>>>>> to 0b10 (short address). The use of long addresses is a REQUIRED as no
>>>>> association procedure is defined in this document.
>>>>>
>>>>> the PAN ID Compression bit MUST be set to 0b0. According to the Table
>>>>> 2a in IEEE802154-2012 this translates into the Destination PAN ID field
>>>>> being "Present" and the Source PAN ID field being "Not Present".
>>>>>
>>>>> I propose the following text which I think is aligned with what has
>>>>> been commented during the discussion.
>>>>>
>>>>>
>>>>> The IEEE802.15.4 header of all frames MUST include the Sequence Number
>>>>> field, the Source Address field and the Destination Address field and only
>>>>> the Destination PANID. Source and destination address fields MUST be filled
>>>>> with an extended address (64 bit) and this be indicated in the
>>>>> corresponding Frame Control field. In case of a destination broadcast
>>>>> address, the address field MUST be filled by a short addresses (16bit). The
>>>>> Destination PANID MUST be present and the Source PANID MUST be elided.
>>>>>
>>>>>
>>>>> Would that work?
>>>>>
>>>>> regards,
>>>>> Xavi
>>>>> _______________________________________________
>>>>> 6tisch mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>>>
>>>>> _______________________________________________
>>>>> 6tisch mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 6tisch mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> 6tisch mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>>
>>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 7 Sep 2015 07:11:01 +0000

Hello Xavi:

I like this text since it makes the normative text mostly independent on IEEE specs and their evolution.

There seems to be an agreement in Prague that the best direction to sort the issues with -2011 would be to align to the next revision so that everybody is ready for 802.15.4-2015. I’ve been wondering how and where to reflect that, like a few words in the annex with the IE examples. Any suggestion?

Some quick notes:

The packet formats are specific for the [IEEE802154-2012]
   revision and MAY vary in future releases of the IEEE standard.

I’d suggest to lowercase that MAY, this text is not normative. On the side, I’d also lowercase the text in the introduction, in particular the MUST.

I had second thoughts about the

Number of available frequencies    | 16

Shouldn’t we allow a given configuration to blacklist / whitelist some ?

Looking at section 4, I’d rather indicate what the goal is as opposed to how it is encoded and then indicate how it is encoded in the current IEEE specs. e.g:

      the PAN ID Compression bit MUST be set to 0b0.  According to the

      Table 2a in [IEEE802154-2012], this translates into the

      Destination PAN ID field being "Present" and the Source PAN ID

      field being "Not Present".

This text has an expectation on encoding that may change. Suggestion is to change to:

      the PAN ID Compression MUST indicate that the

      Destination PAN ID field is "Present" and the Source PAN ID

      field is "Not Present". With [IEEE802154-2012] and according to

      Table 2a, this is accomplished by setting the PAN ID Compression

      bit to 0b0.

   Unicast frames sent to a unicast MAC destination address request an

   acknowledgment.

Somehow this sentence was truncated?

One RECOMMENDED way to achieve this in an

      interoperable fashion is to set Sp to 2*ETX.

Just a reminder that we discussed in Prague that we should use (3*ETX -2) so that an ETX of A would result in MINIMUM_STEP_OF_RANK of 1

All the best,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: lundi 7 septembre 2015 05:30
To: [email-masked]
Cc: Robert Cragie <[email-masked]>; José Ángel Miranda <[email-masked]>; Jonathan Simon <[email-masked]>; Pat Kinney <[email-masked]>
Subject: Re: [6tisch] comments on 15.4 header fields in minimal

Dear all,

after the last WG webex meeting on Friday we decided to finalize this discussion and come out with a proposal on the IEEE802.15.4 specific header fields and what minimal should say about that.

and

My proposal is to find a text for minimal that does not restrict the implementation to any version of 15.4 but instead indicates that the (PANID Compression bit) is used according to the underlying 15.4 version implemented.

here a proposal:

"The IEEE802.15.4 header of all frames MUST include the Sequence Number field, the Source Address field and the Destination Address field and only the Destination PANID. Frame Version field MUST be set to 0b10 (Frame Version 2).
When using  DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types 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. The Destination PANID MUST be present, the Source PANID MUST be elided and the PANID Compression bit MUST be set or clear according to the specific IEEE802.15.4 implementation. "

As per Jose (Kirale) email there are several cases where this implementation would require a special handling of packets when running in minimal compliant mode. Although this might work, maybe is time to also make things simple and not force another set of IF cases to support that mode.

Finally, note that this is for minimal, which is a fallback mode of operation or used for initial interop testing. This means that this mode of operation is not the one that will be running in most of the networks all the time but instead will be switched on when something fails or the network initializes.

regards,
Xavi

2015-07-27 11:00 GMT+02:00 Robert Cragie <[email-masked]<mailto:[email-masked]>>:
For some reason, it was deemed necessary to change PAN ID compression in 802.15.4-2012 for frame version 2 but there is an issue with the case where:

In this case the inferred PAN ID is 0xffff but it is not possible to distinguish an identical short address which may be allocated in different PANs. So I believe the decision was to keep the original format for PAN ID compression where either or both are short addresses but to change the behaviour if both addresses are extended addresses. I have already pointed out that this is a significant change from frame version 0/1 and changes the meaning for PAN ID compression. See the analysis document I sent out earlier.

I don't actually see how 802.15.4e-2012 Table 2a can actually be used as it is erroneous as described above. I would be interested to know if anyone is doing it this way, especially using PAN ID compression set to 1.

Robert

On 27 July 2015 at 05:52, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

we discussed this concern at the IETF meeting. In minimal we wanted to support what is already standardized (15.4e-2012) but it seems that if we make things align to 2012 then we won't be compatible with 2015. If we try to make the text less specific aiming to have people use the table they want we loose some how the sense of minimal as different people implementing it will have different configurations (specially PIDC bits set).

So, what do we do?

2015-07-26 2:50 GMT+02:00 Jonathan Simon <[email-masked]<mailto:[email-masked]>>:
I noticed I said 15.4-2012 in my previous email.  I meant 15.4e-21012 in case it wasn't clear.

On Sat, Jul 25, 2015 at 11:39 AM, Robert Cragie <[email-masked]<mailto:[email-masked]>> wrote:
I too have some concerns with the way the PAN ID compression is used for frame version 2. Please see attached analysis regarding PAN ID compression.

Robert

On 24 July 2015 at 21:00, Jonathan Simon <[email-masked]<mailto:[email-masked]>> wrote:
Pat - I’m noticing some differences between the proposed table and the one in 15.4-2012.

So the PIDC bit is inverted from the previous version for some address sizes, but for both extended addresses (new table row 7), you keep the original sense:

This breaks backward compatibility for older applications that weren’t considering address size.

There is no row in the new table that corresponds to 2012 row 13 for mixed or short addresses.  This breaks our existing IP product implementation.

--
Jonathan

On Jul 21, 2015, at 11:26 PM, Pat Kinney <[email-masked]<mailto:[email-masked]>> wrote:

As per our 6tisch meeting yesterday concerning the PAN ID compression bit table, I have attached an IEEE 802.15 document showing the changes to the latest revision draft. This document will act as guidance to the Technical Editor to modify the revision draft.  In summary, it was agreed that frames of version numbers “0” or “1" should revert to the instructions stated in IEEE 802.15.4-2011.  For frame version “2", new text will be inserted into the revision declaring the rules in a non-ambiguous fashion.

I would ask those interested in setting the header bits to read this document and respond with critiques or questions.

Thanks, Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715<tel:%2B1.847.960.3715>
[email-masked]<mailto:[email-masked]>

<15-15-0561-03-0mag-yet-another-document-explaining-pan-id-compression (1).docx>

On 21, Jul2015, at 12:46, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

From the discussion today, the section mandating the use of certain 2012 specific configuration needs to be changed so we can be independent to the evolution of the 15.4 spec.

The current text is:

The IEEE802.15.4 header of all frames MUST include the Sequence Number field, the Source Address field and the Destination Address field.
In the Frame Control Field, this translates to:

the Destination Addressing Mode MUST set to 0b11 (long address) except for the broadcast address for which Destination Addressing Mode SHOULD set to 0b10 (short address). The use of long addresses is a REQUIRED as no association procedure is defined in this document.

the PAN ID Compression bit MUST be set to 0b0. According to the Table 2a in IEEE802154-2012 this translates into the Destination PAN ID field being "Present" and the Source PAN ID field being "Not Present".

I propose the following text which I think is aligned with what has been commented during the discussion.

The IEEE802.15.4 header of all frames MUST include the Sequence Number field, the Source Address field and the Destination Address field and only the Destination PANID. Source and destination address fields MUST be filled with an extended address (64 bit) and this be indicated in the corresponding Frame Control field. In case of a destination broadcast address, the address field MUST be filled by a short addresses (16bit). The Destination PANID MUST be present and the Source PANID MUST be elided.

Would that work?

regards,
Xavi
_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 9 Sep 2015 08:38:10 +0200

Hi Pascal, All,

thanks. I addressed your comments.

As a note about this:

I would prefer to let it as is, i.e we say we have 16 available
frequencies, but we do not restrict to use all of them or a subset. We just
say that 16 are available.

Another important point that is missing is related to this comment pointed
out by Jose Angel Miranda.

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.

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.

Note also that the first sentence of this section enforces the following:

"The IEEE802.15.4 header of all frames MUST include the Sequence
Number field, the Source Address field and the Destination Address
field. Frame Version field MUST be set to 0b10 (Frame Version 2)."

Please provide your input on this topic (specially those having
running code and networks already deployed).

Regards,

Xavi

2015-09-07 9:11 GMT+02:00 Pascal Thubert (pthubert) <[email-masked]>:

> There seems to be an agreement in Prague that the best direction to sort
> the issues with -2011 would be to align to the next revision so that
> everybody is ready for 802.15.4-2015. I’ve been wondering how and where to
> reflect that, like a few words in the annex with the IE examples. Any
> suggestion?
>
>
>
>
>
> Some quick notes:
>
>
>
>
>
>
>
> I’d suggest to lowercase that MAY, this text is not normative. On the
> side, I’d also lowercase the text in the introduction, in particular the
> MUST.
>
>
>
>
>
>
>
>
>
> Looking at section 4, I’d rather indicate what the goal is as opposed to
> how it is encoded and then indicate how it is encoded in the current IEEE
> specs. e.g:
>
>
>
>
>
> Just a reminder that we discussed in Prague that we should use (3*ETX -2)
> so that an ETX of A would result in MINIMUM_STEP_OF_RANK of 1
>
>
>
>
>
>
>
>
>
> All the best,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Xavier
> Vilajosana
> *Sent:* lundi 7 septembre 2015 05:30
> *To:* [email-masked]
> *Cc:* Robert Cragie <[email-masked]>; José Ángel Miranda <
> [email-masked]>; Jonathan Simon <[email-masked]>; Pat Kinney <
> [email-masked]>
> *Subject:* Re: [6tisch] comments on 15.4 header fields in minimal
>
>
>
> Dear all,
>
>
>
> On 27 July 2015 at 05:52, Xavier Vilajosana <[email-masked]>
> wrote:
>
> Hi,
>
>
>
> I too have some concerns with the way the PAN ID compression is used for
> frame version 2. Please see attached analysis regarding PAN ID compression.
>
>
>
> Robert
>
>
>
> There is no row in the new table that corresponds to 2012 row 13 for mixed
> or short addresses.  This breaks our existing IP product implementation.
>
>
>
> --
> Jonathan
>
>
>
> As per our 6tisch meeting yesterday concerning the PAN ID compression bit
> table, I have attached an IEEE 802.15 document showing the changes to the
> latest revision draft. This document will act as guidance to the Technical
> Editor to modify the revision draft.  In summary, it was agreed that frames
> of version numbers “0” or “1" should revert to the instructions stated in
> IEEE 802.15.4-2011.  For frame version “2", new text will be inserted into
> the revision declaring the rules in a non-ambiguous fashion.
>
>
>
> On 21, Jul2015, at 12:46, Xavier Vilajosana <[email-masked]>
> wrote:
>
>
>
> Hi,
>
>
>
> From the discussion today, the section mandating the use of certain 2012
> specific configuration needs to be changed so we can be independent to the
> evolution of the 15.4 spec.
>
>
>
> The current text is:
>
>
>
> the Destination Addressing Mode MUST set to 0b11 (long address) except for
> the broadcast address for which Destination Addressing Mode SHOULD set to
> 0b10 (short address). The use of long addresses is a REQUIRED as no
> the PAN ID Compression bit MUST be set to 0b0. According to the Table 2a
> in IEEE802154-2012 this translates into the Destination PAN ID field being
> "Present" and the Source PAN ID field being "Not Present".
>
>
>

---

From: Tom Phinney <[email-masked]>
Date: Wed, 9 Sep 2015 07:15:36 -0700

[The following summary is from memory, based on detailed analysis
years ago to make ISA 100.11a into an IEC standard that defaults to,
and can be configured to, conform to European Norms.]

Blacklisting frequencies does not change "the number of available
frequencies"; it merely declares that specific "available
frequencies" in the spread-spectrum rotation cycle are never to be
used.

It may appear to the casual reader that these two concepts are the
same, but in terms of EN 300 328, the regulations that apply to use
of 2.4 GHz spread-spectrum signaling in the EC, they are not.
Reducing the number of distinct frequencies in the spread-spectrum
rotation cycle to less than 16 makes use of IEEE 802.15.4 at needed
power levels illegal in the European Community, due to the
requirements of EN 300 328 that apply when operating at power levels
above 1 mW EIRP.

EN 300 328 v1.8.1 is the the current relevant regulation, which will
soon be replaced by EN 300 328 v1.9.1. Both require that devices
operating under IEEE 802.15.4 and similar regimes have a
spread-spectrum schedule with at least 16 distinct non-overlapping
frequency channels. EN 300 328 does not require that all of the
frequencies be used, but only that time is allocated in the schedule
rotation for their use. Thus blacklisting some of the 16 frequency
channels while leaving them in the spread-spectrum rotation schedule
enables IEEE 802.15.4 to meet the EN 300 328 requirements, whereas
operation at needed transmit power levels would become prohibited if
the spread-spectrum rotation were reduced to fewer than 16 frequency
channels.

-Tom

====

On 2015.09.08 23:38, Xavier Vilajosana
wrote:

Hi Pascal, All,

As a note about this:

Shouldn’t
we allow a given configuration to blacklist / whitelist
some ?

I would prefer to let it as is, i.e we say we have 16
available frequencies, but we do not restrict to use all of
them or a subset. We just say that 16 are available.

Another
important point that is missing is related to this comment
pointed out by Jose Angel Miranda.

- Source PANID: Present.

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.

"The IEEE802.15.4 header of all frames MUST include the Sequence Number field, the Source Address field and the Destination Address field. Frame Version field MUST be set to 0b10 (Frame Version 2)."

Please provide your input on this topic (specially those having running code and networks already deployed).

Regards,

Xavi

2015-09-07 9:11 GMT+02:00 Pascal
Thubert (pthubert) <[email-masked]>:

Hello
Xavi:

I
like this text since it makes the normative text
mostly independent on IEEE specs and their
evolution.

There
seems to be an agreement in Prague that the best
direction to sort the issues with -2011 would be to
align to the next revision so that everybody is
ready for 802.15.4-2015. I’ve been wondering how and
where to reflect that, like a few words in the annex
with the IE examples. Any suggestion?

Some
quick notes:

The packet formats are specific for the
[IEEE802154-2012]

revision and MAY vary in future
releases of the IEEE standard.

I’d
suggest to lowercase that MAY, this text is not
normative. On the side, I’d also lowercase the text
in the introduction, in particular the MUST.

Shouldn’t
we allow a given configuration to blacklist /
whitelist some ?

Looking
at section 4, I’d rather indicate what the goal is
as opposed to how it is encoded and then indicate
how it is encoded in the current IEEE specs. e.g:

This
text has an expectation on encoding that may change.
Suggestion is to change to:

bit to 0b0.

acknowledgment.

Somehow
this sentence was truncated?

Just
a reminder that we discussed in Prague that we
should use (3*ETX -2) so that an ETX of A would
result in MINIMUM_STEP_OF_RANK of 1

All
the best,

Pascal

From:
6tisch [mailto:[email-masked]]
On Behalf Of Xavier Vilajosana

To: [email-masked]

Cc: Robert Cragie <[email-masked]>;
José Ángel Miranda <[email-masked]>;
Jonathan Simon <[email-masked]>;
Pat Kinney <[email-masked]>

Subject: Re: [6tisch] comments on 15.4
header fields in minimal

Dear all,

after the last WG webex
meeting on Friday we decided to finalize
this discussion and come out with a proposal
on the IEEE802.15.4 specific header fields
and what minimal should say about that.

the threads where this is
being discussed are:

and

My proposal is to find a
text for minimal that does not restrict the
implementation to any version of 15.4 but
instead indicates that the (PANID
Compression bit) is used according to the
underlying 15.4 version implemented.

here a proposal:

"The IEEE802.15.4
header of all frames MUST include the
Sequence Number field, the Source Address
field and the Destination Address field
and only the Destination PANID. Frame
Version field MUST be set to 0b10 (Frame
Version 2).

When using  DATA,
ACKNOWLEDGEMENT, MAC COMMAND frame types
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. The
Destination PANID MUST be present, the
Source PANID MUST be elided and the PANID
Compression bit MUST be set or clear
according to the specific IEEE802.15.4
implementation. "

As per Jose (Kirale)
email there are several cases where this
implementation would require a special
handling of packets when running in minimal
compliant mode. Although this might work,
maybe is time to also make things simple and
not force another set of IF cases to support
that mode.

Finally, note that this
is for minimal, which is a fallback mode of
operation or used for initial interop
testing. This means that this mode of
operation is not the one that will be
running in most of the networks all the time
but instead will be switched on when
something fails or the network initializes.

regards,

Xavi

2015-07-27 11:00
GMT+02:00 Robert Cragie <[email-masked]>:

For some reason, it
was deemed necessary to change PAN ID
compression in 802.15.4-2012 for frame
version 2 but there is an issue with the
case where:

* both addresses
are present

* either or both is
a short address

* PAN ID
compression is set to 1

In this case the
inferred PAN ID is 0xffff but it is
not possible to distinguish an
identical short address which may be
allocated in different PANs. So I
believe the decision was to keep the
original format for PAN ID compression
where either or both are short
addresses but to change the behaviour
if both addresses are extended
addresses. I have already pointed out
that this is a significant change from
frame version 0/1 and changes the
meaning for PAN ID compression. See
the analysis document I sent out
earlier.

I don't actually
see how 802.15.4e-2012 Table 2a can
actually be used as it is erroneous as
described above. I would be interested
to know if anyone is doing it this
way, especially using PAN ID
compression set to 1.

Robert

On 27 July 2015
at 05:52, Xavier Vilajosana <[email-masked]>
wrote:

Hi,

we
discussed this concern at
the IETF meeting. In minimal
we wanted to support what is
already standardized
(15.4e-2012) but it seems
that if we make things align
to 2012 then we won't be
compatible with 2015. If we
try to make the text less
specific aiming to have
people use the table they
want we loose some how the
sense of minimal as
different people
implementing it will have
different configurations
(specially PIDC bits set).

So, what
do we do?

2015-07-26
2:50 GMT+02:00 Jonathan
Simon <[email-masked]>:

I
noticed I said
15.4-2012 in my
previous email.  I
meant 15.4e-21012 in
case it wasn't
clear.

On
Sat, Jul 25,
2015 at 11:39
AM, Robert
Cragie <[email-masked]>
wrote:

I
too have some
concerns with
the way the
PAN ID
compression is
used for frame
version 2.
Please see
attached
analysis
regarding PAN
ID
compression.

Robert

On
24 July 2015
at 21:00,
Jonathan Simon
<[email-masked]>
wrote:

Pat
- I’m noticing
some
differences
between the
proposed table
and the one in
15.4-2012.

In
15.4-2012, the
last 2 rows of
table 2a are

SRC addr   DST addr    SRC PAN          DST
PAN
PIDC

Present    Present     Not Present
Present
0    (row
12)

Present    Present     Not Present      Not
Present     1
(row 13)

In
the proposed
table, rows
12-14
correspond to
the 2012 row
12 case

SRC addr   DST addr    SRC PAN          DST
PAN
PIDC

Extended
Short
Not Present
Present
1

Short
Extended
Not Present
Present
1

Short
Short
Not Present
Present
1

So
the PIDC bit
is inverted
from the
previous
version for
some address
sizes, but for
both extended
addresses (new
table row 7),
you keep the
original
sense:

SRC addr   DST addr    SRC PAN          DST
PAN
PIDC

Extended
Extended
Not Present
Present
1

This
breaks
backward
compatibility
for older
applications
that weren’t
considering
address size.

There
is no row in
the new table
that
corresponds to
2012 row 13
for mixed or
short
addresses.
This breaks
our existing
IP product
implementation.

--

Jonathan

On
Jul 21, 2015,
at 11:26 PM,
Pat Kinney
<[email-masked]>
wrote:

As
per our 6tisch
meeting
yesterday
concerning the
PAN ID
compression
bit table, I
have attached
an IEEE 802.15
document
showing the
changes to the
latest
revision
draft. This
document will
act as
guidance to
the Technical
Editor to
modify the
revision
draft.  In
summary, it
was agreed
that frames of
version
numbers “0” or
“1" should
revert to the
instructions
stated in IEEE
802.15.4-2011.
For frame
version “2",
new text will
be inserted
into the
revision
declaring the
rules in a
non-ambiguous
fashion.

I
would ask
those
interested in
setting the
header bits to
read this
document and
respond with
critiques or
questions.

Thanks,
Pat

Pat
Kinney

Kinney
Consulting LLC

IEEE
802.15 WG vice
chair, TG
chair

ISA100.11a
WG chair

O:
+1.847.960.3715

On
21, Jul2015,
at 12:46,
Xavier
Vilajosana
<[email-masked]>
wrote:

Hi,

From
the discussion
today, the
section
mandating the
use of certain
2012 specific
configuration
needs to be
changed so we
can be
independent to
the evolution
of the 15.4
spec.

The
current text
is:

The
IEEE802.15.4
header of all
frames MUST
include the
Sequence
Number field,
the Source
Address field
and the
Destination
Address field.

In
the Frame
Control Field,
this
translates to:

the
Frame Version
field MUST be
set to 0b10
(Frame Version
2)

the
Sequence
Number
Suppression
bit MUST be
set to 0b0

the
Source
Addressing
Mode MUST set
to 0b11 (long
address)

the
Destination
Addressing
Mode MUST set
to 0b11 (long
address)
except for the
broadcast
address for
which
Destination
Addressing
Mode SHOULD
set to 0b10
(short
address). The
use of long
addresses is a
REQUIRED as no
association
procedure is
defined in
this document.

the
PAN ID
Compression
bit MUST be
set to 0b0.
According to
the Table 2a
in
IEEE802154-2012
this
translates
into the
Destination
PAN ID field
being
"Present" and
the Source PAN
ID field being
"Not Present".

I
propose the
following text
which I think
is aligned
with what has
been commented
during the
discussion.

The
IEEE802.15.4
header of all
frames MUST
include the
Sequence
Number field,
the Source
Address field
and the
Destination
Address field
and only the
Destination
PANID. Source
and
destination
address fields
MUST be filled
with an
extended
address (64
bit) and this
be indicated
in the
corresponding
Frame Control
field. In case
of a
destination
broadcast
address, the
address field
MUST be filled
by a short
addresses
(16bit). The
Destination
PANID MUST be
present and
the Source
PANID MUST be
elided.

Would
that work?

regards,

Xavi

6tisch mailing
list

[email-masked]

6tisch mailing
list

[email-masked]

6tisch mailing
list

[email-masked]

6tisch mailing list

[email-masked]

---

From: Jonathan Simon <[email-masked]>
Date: Wed, 9 Sep 2015 13:38:59 -0700

Xavi - sorry I've been neglecting 6TiSCH lately. You don't need DSN to
match packet and ACK - they use the same ASN so link-layer security will
make sure packet matches ACK.

Otherwise +1

On Tue, Sep 8, 2015 at 11:38 PM, Xavier Vilajosana <
[email-masked]> wrote:

>> On 27 July 2015 at 05:52, Xavier Vilajosana <

-- 
-- 
Jonathan Simon
Director of Systems Engineering
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
(510) 400-2936
(510) 489-3799 FAX
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Sep 2015 07:15:30 +0000

Hello Tom:

Thanks a lot for all this!

Several questions:

-        I understand that you largely contributed the text in the 62734 specification that deals with ETSI compliance. That text would be of great value for this list. Would you have a link that you could share?

-        About the rotation cycle below, I understand that you are indicating that we should use 16 to comply with ETSI, and go through the usual pseudo-random sequence with the 16 channels, but then when reaching a blacklisted channel we’d just refrain from transmitting. IOW we divide the bandwidth by 16/white_listed_channels, correct?

-        Your recommendation is more specifically to avoid to have less than 15 channels in the hopping sequence so as to qualify as a frequency hopper; this coupled with the latest 802.15.4 CCA setting would make a minimal node an adaptive FH. Is that correct?

-        But if the number of time slots in the schedule is above 10 to maintain the Medium Utilisation factor low, since minimal operates alone and only on the first time slot, then minimal could claim to be a duty cycled non FH, couldn’t it?

Take care,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Tom Phinney
Sent: mercredi 9 septembre 2015 16:16
To: [email-masked]
Subject: Re: [6tisch] comments on 15.4 header fields in minimal

[The following summary is from memory, based on detailed analysis years ago to make ISA 100.11a into an IEC standard that defaults to, and can be configured to, conform to European Norms.]

Blacklisting frequencies does not change "the number of available frequencies"; it merely declares that specific "available frequencies" in the spread-spectrum rotation cycle are never to be used.

It may appear to the casual reader that these two concepts are the same, but in terms of EN 300 328, the regulations that apply to use of 2.4 GHz spread-spectrum signaling in the EC, they are not. Reducing the number of distinct frequencies in the spread-spectrum rotation cycle to less than 16 makes use of IEEE 802.15.4 at needed power levels illegal in the European Community, due to the requirements of EN 300 328 that apply when operating at power levels above 1 mW EIRP.

EN 300 328 v1.8.1 is the the current relevant regulation, which will soon be replaced by EN 300 328 v1.9.1. Both require that devices operating under IEEE 802.15.4 and similar regimes have a spread-spectrum schedule with at least 16 distinct non-overlapping frequency channels. EN 300 328 does not require that all of the frequencies be used, but only that time is allocated in the schedule rotation for their use. Thus blacklisting some of the 16 frequency channels while leaving them in the spread-spectrum rotation schedule enables IEEE 802.15.4 to meet the EN 300 328 requirements, whereas operation at needed transmit power levels would become prohibited if the spread-spectrum rotation were reduced to fewer than 16 frequency channels.

-Tom
====
On 2015.09.08 23:38, Xavier Vilajosana wrote:
Hi Pascal, All,

As a note about this:

I would prefer to let it as is, i.e we say we have 16 available frequencies, but we do not restrict to use all of them or a subset. We just say that 16 are available.

Another important point that is missing is related to this comment pointed out by Jose Angel Miranda.

-          Source PANID: Present.

Regards,

Xavi

2015-09-07 9:11 GMT+02:00 Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
Hello Xavi:

Some quick notes:

      bit to 0b0.

   acknowledgment.

All the best,

Pascal

From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Xavier Vilajosana
Sent: lundi 7 septembre 2015 05:30
To: [email-masked]<mailto:[email-masked]>
Cc: Robert Cragie <[email-masked]<mailto:[email-masked]>>; José Ángel Miranda <[email-masked]<mailto:[email-masked]>>; Jonathan Simon <[email-masked]<mailto:[email-masked]>>; Pat Kinney <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tisch] comments on 15.4 header fields in minimal

Dear all,

and

here a proposal:

regards,
Xavi

Robert

So, what do we do?

Robert

--
Jonathan

Thanks, Pat

Pat Kinney
Kinney Consulting LLC

Hi,

The current text is:

Would that work?

regards,
Xavi

6tisch mailing list

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 10 Sep 2015 14:38:29 +0300

> (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.

> 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-masked]

---

From: Tom Phinney <[email-masked]>
Date: Thu, 10 Sep 2015 16:03:23 -0700

Pascal, I have added numbers to the items in your query so that I
can respond to them individually.

1) The IEC 62734 standard is copyright IEC and available for
purchase from their website for a significant price. EN 300 328
v1.8.1 and v1.9.1 are available via search engines.

2) EN 300 328 v1.8.1, and the newer v1.9.1, do not require that a
6TiSCH schedule have scheduled activity in slots that map to
blacklisted channels. It does require that, for devices that attempt
to qualify under the frequency-hopping classification, the channel
rotation not be shortened to fewer than 15 channels. Therefore, if M
slots (of N >= 15) are blacklisted, the maximum percentage of
slots that can have traffic is M/N.

Thus, in answer to your question, when reaching a slot that maps to
a blacklisted channel, the rational thing would be to leave that
slot empty in the schedule, so that no attempt to queue an
impermissible transmission even occurs. EN 300 328 does not require
that the slot be scheduled; it only requires that the transmission
pattern not attempt to use any one of the slots more frequently (on
average) than 1/15 of the time, as measured over assessment
intervals specified in the EN.

3) That is correct. The number of channels in the rotation cycle is
important only when attempting to operate at TX power levels above
+13 dBm. Operation under the frequency-hopping rules with at least
15 channels in the channel cycle permits higher transmit power (and
thus wider-area coverage) than when fewer channels are used. See the
next answer for details.

4) My analysis of EN 300 328, which is in IEC 62734 Annex V, permits
any IEEE 802.15.4 device to operate under a variety of regimes. I
have attempted to summarize the material in IEC 62734 Annex V in the
following paragraphs:

a) Without employing duty cycle limitation, any IEEE 802.15.4 device
qualifies to operate under EN 300 328 as using low-power "wideband
modulation (WBM)" with transmit power limited to +10 mW EIRP (i.e.,
+10 dBm). Note that +10 dBm is sufficient to support any device
provisioning phase that is performed physically proximate to the
equipment (e.g., by an installer or when parts are placed in
inventory).

b) When duty-cycle limitation is employed, any IEEE 802.15.4 device
qualifies to operate under EN 300 328 as using WBM with transmit
power limited to +20 mW EIRP (i.e., +13 dBm). The duty-cycle
limitation can be realized either

i) by using listen-before-talk (LBT) or

ii) by ensuring (through device construction or self-monitoring)
that the average power output over any (i.e., every possible) 1,0
second measurement interval is +10 mW EIRP or less (i.e., a duty
cycle of 50% or less for a +13 dBm device).

c) If an IEEE 802.15.4 device has a slot schedule that involves at
least 15 disjoint RF channels, whether some are consistently unused
or not, then the device also qualifies as a "frequency-hopping
spread-spectrum modulation" (FHSSM) device. In that case, when
duty-cycle limitation is employed, its maximum permitted transmit
power under EN 300 328 is +100 mW EIRP (i.e., +20 dBm). In this case
the duty-cycle limitation can be realized either

i) by using LBT or

ii) by ensuring (through device construction or self-monitoring)
that the average power output over any (i.e., every possible)
100-slot measurement interval is +10 mW EIRP or less (i.e., a duty
cycle of 10% or less for a +20 dBm device).

For devices in categories 4b)ii) and 4c)ii), i.e., that do not use
LBT, there is a required TX-gap time of non-transmission after each
IEEE 802.15.4 Data-frame transmission. This requirement is met
automatically for slot durations of 10 ms or greater.

ACK/NAK immediate-response PDUs qualify as "short control signaling
(SCS)" under EN 300 328, whether they use IEEE 802.15.4's unsecured
ACK-frame format or a secured Data-frame format. In cases b)ii) and
c), there is also a required TX-gap time after transmitting an
ACK/NAK immediate-response PDU. This requirement can prevent a
device that sends an ACK/NAK at the end of one time slot from being
able to transmit a Data-frame in the next time slot.

Since it is sent as an immediate response, short control signaling
is always non-adaptive (i.e., presumably cannot use LBT). Thus the
average power limitations of b)ii) or c)ii) apply to SCS
transmission from a device. This is unlikely to be a problem for
field devices, but the limitation on total TX power for ACK/NAK
immediate responses could limit backbone routers when receiving and
acknowledging bursts of Data-frames received from field devices.

I hope that this summary adds some clarity to the issue. The number
of channels in the rotation cycle is important only when attempting
to operate at TX power levels above +13 dBm.

-Tom

====

On 2015.09.10 00:15, Pascal Thubert
(pthubert) wrote:

Hello
Tom:

Thanks
a lot for all this!

Several
questions:

1)
I
understand that you largely contributed the text in the
62734 specification that deals with ETSI compliance. That
text would be of great value for this list. Would you have a
link that you could share?

2)
About
the rotation cycle below, I understand that you are
indicating that we should use 16 to comply with ETSI, and go
through the usual pseudo-random sequence with the 16
channels, but then when reaching a blacklisted channel we'd
just refrain from transmitting. IOW we divide the bandwidth
by 16/white_listed_channels, correct?

3)
Your
recommendation is more specifically to avoid to have less
than 15 channels in the hopping sequence so as to qualify as
a frequency hopper; this coupled with the latest 802.15.4
CCA setting would make a minimal node an adaptive FH. Is
that correct?

4)
But
if the number of time slots in the schedule is above 10 to
maintain the Medium Utilisation factor low, since minimal
operates alone and only on the first time slot, then minimal
could claim to be a duty cycled non FH, couldn't it?

Take
care,

Pascal

From:
On Behalf Of Tom Phinney

To: [email-masked]

Subject: Re: [6tisch] comments on 15.4 header
fields in minimal

[The following summary is from memory,
based on detailed analysis years ago to make ISA 100.11a
into an IEC standard that defaults to, and can be configured
to, conform to European Norms.]

Blacklisting frequencies does not change "the number of
available frequencies"; it merely declares that specific
"available frequencies" in the spread-spectrum rotation
cycle are never to be used.

It may appear to the casual reader that these two concepts
are the same, but in terms of EN 300 328, the regulations
that apply to use of 2.4 GHz spread-spectrum signaling in
the EC, they are not. Reducing the number of distinct
frequencies in the spread-spectrum rotation cycle to less
than 16 makes use of IEEE 802.15.4 at needed power levels
illegal in the European Community, due to the requirements
of EN 300 328 that apply when operating at power levels
above 1 mW EIRP.

EN 300 328 v1.8.1 is the the current relevant regulation,
which will soon be replaced by EN 300 328 v1.9.1. Both
require that devices operating under IEEE 802.15.4 and
similar regimes have a spread-spectrum schedule with at
least 16 distinct non-overlapping frequency channels. EN 300
328 does not require that all of the frequencies be used,
but only that time is allocated in the schedule rotation for
their use. Thus blacklisting some of the 16 frequency
channels while leaving them in the spread-spectrum rotation
schedule enables IEEE 802.15.4 to meet the EN 300 328
requirements, whereas operation at needed transmit power
levels would become prohibited if the spread-spectrum
rotation were reduced to fewer than 16 frequency channels.

-Tom

====

Hi Pascal, All,

As a note about this:

Shouldnâ€™t

I would prefer to let it as is, i.e we say we have
16 available frequencies, but we do not restrict
to use all of them or a subset. We just say that
16 are available.

Another
important point that is missing is related to this
comment pointed out by Jose Angel Miranda.

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â€¦â€

-          Source PANID: Present.

Regards,

Xavi

Hello
Xavi:

I
like this text since it makes the normative
text mostly independent on IEEE specs and
their evolution.

There
seems to be an agreement in Prague that the
best direction to sort the issues with -2011
would be to align to the next revision so that
everybody is ready for 802.15.4-2015. Iâ€™ve
been wondering how and where to reflect that,
like a few words in the annex with the IE
examples. Any suggestion?

Some
quick notes:

The packet formats are
specific for the [IEEE802154-2012]

revision and MAY vary in
future releases of the IEEE standard.

Iâ€™d
suggest to lowercase that MAY, this text is
not normative. On the side, Iâ€™d also
lowercase the text in the introduction, in
particular the MUST.

Shouldnâ€™t

Looking
at section 4, Iâ€™d rather indicate what the
goal is as opposed to how it is encoded and
then indicate how it is encoded in the current
IEEE specs. e.g:

This
text has an expectation on encoding that may
change. Suggestion is to change to:

bit to 0b0.

acknowledgment.

Somehow

Just
a reminder that we discussed in Prague that we
should use (3*ETX -2) so that an ETX of A
would result in MINIMUM_STEP_OF_RANK of 1

All
the best,

Pascal

From:

Sent: lundi 7 septembre 2015
05:30

To: [email-masked]

Cc: Robert Cragie <[email-masked]>;
JosÃ© Ãngel Miranda <[email-masked]>;
Jonathan Simon <[email-masked]>;

Subject: Re: [6tisch] comments on
15.4 header fields in minimal

Dear
all,

after
the last WG webex meeting on Friday we
decided to finalize this discussion
and come out with a proposal on the
IEEE802.15.4 specific header fields
and what minimal should say about
that.

the
threads where this is being discussed
are:

and

My
proposal is to find a text for minimal
that does not restrict the
implementation to any version of 15.4
but instead indicates that the (PANID
Compression bit) is used according to
the underlying 15.4 version
implemented.

here
a proposal:

"The
IEEE802.15.4 header of all frames
MUST include the Sequence Number
field, the Source Address field and
the Destination Address field and
only the Destination PANID. Frame
Version field MUST be set to 0b10
(Frame Version 2).

When
using  DATA, ACKNOWLEDGEMENT, MAC
COMMAND frame types 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.
The Destination PANID MUST be
present, the Source PANID MUST be
elided and the PANID Compression bit
MUST be set or clear according to
the specific IEEE802.15.4
implementation. "

As
per Jose (Kirale) email there are
several cases where this
implementation would require a special
handling of packets when running in
minimal compliant mode. Although this
might work, maybe is time to also make
things simple and not force another
set of IF cases to support that mode.

Finally,
note that this is for minimal, which
is a fallback mode of operation or
used for initial interop testing. This
means that this mode of operation is
not the one that will be running in
most of the networks all the time but
instead will be switched on when
something fails or the network
initializes.

regards,

Xavi

2015-07-27
11:00 GMT+02:00 Robert Cragie <[email-masked]>:

For
some reason, it was deemed
necessary to change PAN ID
compression in 802.15.4-2012 for
frame version 2 but there is an
issue with the case where:

*
both addresses are present

*
either or both is a short
address

*
PAN ID compression is set to 1

In
this case the inferred PAN ID is
0xffff but it is not possible to
distinguish an identical short
address which may be allocated
in different PANs. So I believe
the decision was to keep the
original format for PAN ID
compression where either or both
are short addresses but to
change the behaviour if both
addresses are extended
addresses. I have already
pointed out that this is a
significant change from frame
version 0/1 and changes the
meaning for PAN ID compression.
See the analysis document I sent
out earlier.

I
don't actually see how
802.15.4e-2012 Table 2a can
actually be used as it is
erroneous as described above. I
would be interested to know if
anyone is doing it this way,
especially using PAN ID
compression set to 1.

Robert

On
27 July 2015 at 05:52,
Xavier Vilajosana <[email-masked]>
wrote:

Hi,

we
discussed this concern
at the IETF meeting.
In minimal we wanted
to support what is
already standardized
(15.4e-2012) but it
seems that if we make
things align to 2012
then we won't be
compatible with 2015.
If we try to make the
text less specific
aiming to have people
use the table they
want we loose some how
the sense of minimal
as different people
implementing it will
have different
configurations
(specially PIDC bits
set).

So,
what do we do?

2015-07-26
2:50 GMT+02:00
Jonathan Simon
<[email-masked]>:

I noticed I
said 15.4-2012
in my previous
email.  I
meant
15.4e-21012 in
case it wasn't
clear.

On Sat, Jul
25, 2015 at
11:39 AM,
Robert Cragie
<[email-masked]>
wrote:

I too have
some concerns
with the way
the PAN ID
compression is
used for frame
version 2.
Please see
attached
analysis
regarding PAN
ID
compression.

Robert

On 24 July
2015 at 21:00,
Jonathan Simon
<[email-masked]> wrote:

Pat - Iâ€™m
noticing some
differences
between the
proposed table
and the one in
15.4-2012.

In 15.4-2012,
the last 2
rows of table
2a are

SRC
addr   DST
addr    SRC
PAN
DST PAN
PIDC

Present
Present
Not Present
Present
0    (row
12)

Present
Present
Not Present
Not Present
1    (row
13)

In the
proposed
table, rows
12-14
correspond to
the 2012 row
12 case

SRC
addr   DST
addr    SRC
PAN
DST PAN
PIDC

Extended
Short
Not Present
Present
1

Short
Extended
Not Present
Present
1

Short
Short
Not Present
Present
1

So the PIDC
bit is
inverted from
the previous
version for
some address
sizes, but for
both extended
addresses (new
table row 7),
you keep the
original
sense:

SRC
addr   DST
addr    SRC
PAN
DST PAN
PIDC

Extended
Extended
Not Present
Present
1

This breaks
backward
compatibility
for older
applications
that werenâ€™t
considering
address size.

There is no
row in the new
table that
corresponds to
2012 row 13
for mixed or
short
addresses.
This breaks
our existing
IP product
implementation.

--

Jonathan

On Jul 21,
2015, at 11:26
PM, Pat Kinney

As per our
6tisch meeting
yesterday
concerning the
PAN ID
compression
bit table, I
have attached
an IEEE 802.15
document
showing the
changes to the
latest
revision
draft. This
document will
act as
guidance to
the Technical
Editor to
modify the
revision
draft.  In
summary, it
was agreed
that frames of
version
numbers
â€œ0â€ or
â€œ1" should
revert to the
instructions
stated in IEEE
802.15.4-2011.
For frame
version â€œ2",
new text will
be inserted
into the
revision
declaring the
rules in a
non-ambiguous
fashion.

I would ask
those
interested in
setting the
header bits to
read this
document and
respond with
critiques or
questions.

Thanks, Pat

Pat
Kinney

Kinney
Consulting LLC

IEEE
802.15 WG vice
chair, TG
chair

ISA100.11a
WG chair

O:
+1.847.960.3715

On 21,
Jul2015, at
12:46, Xavier
Vilajosana

Hi,

From the
discussion
today, the
section
mandating the
use of certain
2012 specific
configuration
needs to be
changed so we
can be
independent to
the evolution
of the 15.4
spec.

The current
text is:

The
IEEE802.15.4
header of all
frames MUST
include the
Sequence
Number field,
the Source
Address field
and the
Destination
Address field.

In the Frame
Control Field,
this
translates to:

the Frame
Version field
MUST be set to
0b10 (Frame
Version 2)

the Sequence
Number
Suppression
bit MUST be
set to 0b0

the Source
Addressing
Mode MUST set
to 0b11 (long
address)

the
Destination
Addressing
Mode MUST set
to 0b11 (long
address)
except for the
broadcast
address for
which
Destination
Addressing
Mode SHOULD
set to 0b10
(short
address). The
use of long
addresses is a
REQUIRED as no
association
procedure is
defined in
this document.

the PAN ID
Compression
bit MUST be
set to 0b0.
According to
the Table 2a
in
IEEE802154-2012
this
translates
into the
Destination
PAN ID field
being
"Present" and
the Source PAN
ID field being
"Not Present".

I propose the
following text
which I think
is aligned
with what has
been commented
during the
discussion.

The
IEEE802.15.4
header of all
frames MUST
include the
Sequence
Number field,
the Source
Address field
and the
Destination
Address field
and only the
Destination
PANID. Source
and
destination
address fields
MUST be filled
with an
extended
address (64
bit) and this
be indicated
in the
corresponding
Frame Control
field. In case
of a
destination
broadcast
address, the
address field
MUST be filled
by a short
addresses
(16bit). The
Destination
PANID MUST be
present and
the Source
PANID MUST be
elided.

Would that
work?

regards,

Xavi

6tisch mailing
list

[email-masked]

6tisch mailing
list

[email-masked]

6tisch mailing
list

[email-masked]

6tisch mailing
list

[email-masked]

6tisch mailing list

[email-masked]

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 18 Sep 2015 05:41:29 +0200

Hi Tero,

what is the difference between what you propose in the new version

"I think the current proposal will
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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 21 Sep 2015 14:44:19 +0300

> and  using macImplicitBroadcast?

macImplicitBroadcast does not have any meaning for the scanning. It is
used during the normal operations, i.e. if that is true and you
receive frame without destination address or PAN ID you assume it was
meant to be broadcast message, not message to coordinator. 

> macImplicitBroadcast set to TRUE in order to be able to identify the
> frame? 

Normal case if you do not have destination address, or destination PAN
id you only pass the filtering rules in then "6.7.2 Reception and
rejection" section if the source PAN ID matches the macPanId and you
are coordinator.

If macImplicitBroadcast is true then you ignore the destination
address filters and assume that message was sent to broadcast
addresses if destination addresses are missing

Of course to be able to use macImplicitBroadcast broadcast you need to
be sure that all devices in the network are using same value for this
settings, as otherwise you do not know whether no destination address
means coordinator or whether it mean broadcast.

All this do not have anything to do with scanning.

In the "6.3.1.2 Active and passive channel scan" there is text which
says:

	Before commencing an active or passive scan, the MAC sublayer
	shall store the value of macPanId and then set it to 0xffff
	for the duration of the scan. This enables the receive filter
	to accept all beacons rather than just the beacons from its
	current PAN, as described in 6.7.2. On completion of the scan,
	the MAC sublayer shall restore the value of macPanId to the
	value stored before the scan began.

This was trying to modify the filtering rules in in the 6.7.2 so that
the check like:

	If a destination PAN ID is included in the frame, it shall
	match macPanId or shall be the broadcast PAN ID.

would always match, and that would not filter frames based on the
destination PAN ID. Unfortunately this is completely wrong, as if you
read that test it will match if the detination PAN ID matches macPanId
(0xffff in this case as it was set so in 6.3.1.2), or whether
destination PAN ID is broadcast PAN ID (== 0xffff). I.e. this
statement does not have the same text that is in the Source PAN ID
test, where it actually tests if macPanId is 0xffff, and if frame is
beacon it will pass it through. So the text in the 6.3.1.2 is wrong
when it claims "This enables the receive filter to accept all
beacons". It only allows beacons with any source pan id, but
destination pan id still needs to be broadcast pan id (which I think
it mostly likely always is).

> Therefore,  macImplicitBroadcast set to FALSE, and dst address (short) and dst
> PANID to be explicit (0xffff). 

Yes.

> As a second point:  Would the use of macImplicitBroadcast change in
> the new version?

No, there is no change for that. It is still going to be broken in a
sense that it needs to be same for everybody in the network, and there
is no mechanism to ensure that, but it will still work as before. And
it still does not have anything to do with active or passive scans.
-- 
[email-masked]