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

Thu, 10 Sep 2015 16:03:57 -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: 6tisch [mailto:[email protected]] On Behalf Of Tom Phinney
Sent: mercredi 9 septembre 2015 16:16
To: [email protected]
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,

 

thanks. I addressed your comments. 

 

As a note about this:

 
>>>>>> 
 I had second thoughts about the 
Number of available frequencies    | 16

 

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.

 

>>>>>>>>>>>>>>>>> 

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 protected]>:

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 protected]] On Behalf Of Xavier Vilajosana
Sent: lundi 7 septembre 2015 05:30
To: [email protected]
Cc: Robert Cragie <[email protected]>; José Ángel Miranda <[email protected]>; Jonathan Simon <[email protected]>;


                                Pat Kinney <[email protected]>

                                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 protected]>:

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 protected]> 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 protected]>:

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

 

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

 

On 21, Jul2015, at 12:46, Xavier Vilajosana <[email protected]> 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 protected]
https://www.ietf.org/mailman/listinfo/6tisch

 

_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

 


_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

 

 


_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

 

 

 

 




_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

 



_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch


_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to