Subject: [6tsch] report flow contents

From: Thomas Watteyne <[email-masked]>
Date: Thu, 5 Sep 2013 11:41:16 -0700

*[renamed thread]*

Xavi,

A few thoughts:
- the counters (numTx, etc) will only be present for neighbors the node has
communicate with, so they should be optional in the packet.
- you have focused on the topological information (which I think is the
right one). It might be useful to gather other data related to
synchronization or queuing.
- I couldn't agree more with your suggestion to make it extensible. This
does mean that we will need to state somewhere that a device need to ignore
silently fields it does not understand.

Thomas

On Thu, Sep 5, 2013 at 11:15 AM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

> Hello, I guess that flows are getting defined and I started to think on
> the contents of the messages on that flows. Not sure if this is the right
> time or I am going way far..
>
> According to the previous discussion I assume that the five flows are:
>
> ME-6TOP - Query Flow
> ME-6TOP - Action Flow
>
> 6TOP - ME - Report Flow
> 6TOP - ME - Event Flow
> 6TOP - ME - Request BW Flow
>
> I'd like to start defining the content of the messages in the Report Flow:
>
> The Report Flow: has to deal with the information that a node knows and
> has to be sent to the ME so the ME can compute the schedule among others.
> Here I list  the information that we can know in a mote and can be used at
> the ME to compute the schedule (complete please if I miss something)
>
> For each known neighbor:
>  -ID
>  -AVG RSSI in a running window
>  -Latest RSSI
>  -Num TX packets
>  -Num ACK packets
>  -Num RX packets
>  -Last ASN when it heart about that neighbor
>
> Other fields
>  -Num links in the Schedule to that neighbor
>     -For each link PDR
>
>
> Then we need to have some TLV like objects that can be used for
> ad-hoc/naive/other extensions of the reporting process. In that way we
> don't constraint the implementation of the scheduling alg. to that
> information.
>
> what do you think?
> X
>
>
> On Fri, Aug 30, 2013 at 10:45 AM, Qin Wang <[email-masked]> wrote:
>
>> Hi all,
>>
>> In this thread, we will continue the discussion about Confirmation
>> message. Here is some background information.
>>
>> Context: e.g.
>>     - node sends a report and want to know if the report is accepted.,
>>     - ME sends a action request and want to know if/when the action taken.
>> Options:
>>    (1) Nothing
>>    (2) Rely on transport mechanism (e.g. confirmable CoAP message)
>>    (3) App-level ACK type
>>    (4) Use different flow (i.e. action flow)
>>
>> IMHO, different control flow may have different requirement for
>> confirmation message.
>>     (1) Action Flow, needs a App-level confirmation, like Succ/Fail
>>     (2) Query Flow, automatically has the confirmation, i.e. the message
>> packet corresponding to a specific query.
>>      (3) Report Flow and Event Flow, option (1)-(3) are OK, but I prefer
>> option (1) and (3), i.e. the confirmation message is an option, but if a
>> confirmation message is needed, it should be App-level Ack, instead of
>> transport layer confirmation, which will give 6top more flexibility.
>>
>> What do you think?
>>
>> Thanks
>>  Qin
>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>>
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Thu, 5 Sep 2013 12:47:36 -0700

Hi Thomas, Diego,

I agree that LQI should be there as well. I update here the list with
Thomas suggestions.

For each known neighbor:
 -ID
 -AVG RSSI in a running window
 -Latest RSSI
 -AVG LQI in a running window
 -Latest LQI
 -Num TX packets (option in case there is communication with that neighbor)
 -Num ACK packets (option in case there is communication with that neighbor)
 -Num RX packets (option in case there is communication with that neighbor)
 -Last ASN when it heart about that neighbor

Other fields
 -Num links in the Schedule to that neighbor
    -For each link PDR
 -For each Queue:
    - Avg Queue length in a running window
    - Max Queue length in a running window (peak)
    - Current Queue length (?)
-Time source parent
    -ID
    -Avg clock drift (correction done) in a running window
    -Latest clock correction
    -Parent changes (counter of how many times I changed my time source
parent)

-Option Flag (weather there are optional TLV fields)
   +(TLV objects)*

Hope this makes sense.
cheers!
Xavi

On Thu, Sep 5, 2013 at 11:41 AM, Thomas Watteyne <[email-masked]
> wrote:

> *[renamed thread]*
>
> Xavi,
>
> A few thoughts:
> - the counters (numTx, etc) will only be present for neighbors the node
> has communicate with, so they should be optional in the packet.
>>>      (3) Report Flow and Event Flow, option (1)-(3) are OK, but I
>>> prefer option (1) and (3), i.e. the confirmation message is an option, but
>>> if a confirmation message is needed, it should be App-level Ack, instead of

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 5 Sep 2013 16:03:10 -0700

Xavi,

Fantastic!

I believe PDR for each link might be too long to fit in a packet. While the
mote will most likely keep that information, we could move that to the
query flow, i.e. it is available to the PCE on-demand.

Would you agree that the number of links in a bundle belongs to the
neighbor? Of maybe we want a "bundle" category?

In queuing, it might be interesting to see the age of the different
packets, to be able to monitor latency.

About LQI, there is no general consensus among vendors on what the
definition is, or how exactly it is calculated. I would make it optional.

Also, it might be good to be able to add arbitrary fields to each category:
neighbor, queue, time source neighbor.

Finally, do you envision a generic mechanism whereby the PCE can turn
fields on/off, or triggered independently?

Thomas

On Thu, Sep 5, 2013 at 12:47 PM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

> On Thu, Sep 5, 2013 at 11:41 AM, Thomas Watteyne <
> [email-masked]> wrote:
>
>> *[renamed thread]*
>>
>> Xavi,
>>
>> A few thoughts:
>>>>     (2) Query Flow, automatically has the confirmation, i.e. the
>>>> message packet corresponding to a specific query.

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Thu, 5 Sep 2013 16:17:19 -0700

agreed!
So the fields become:

For each known neighbor:
 -ID
 -AVG RSSI in a running window
 -Latest RSSI
 -AVG LQI in a running window [optional]
 -Latest LQI [optional]
 -Num TX packets (option in case there is communication with that neighbor)
 -Num ACK packets (option in case there is communication with that neighbor)
 -Num RX packets (option in case there is communication with that neighbor)
 -Last ASN when it heart about that neighbor
 -Bundle: Num links in the Schedule to that neighbor
      -PDR per link [Optional -- or maybe best and worst PDR only]

 -Option Flag (weather there are optional TLV fields on that category)
   +(TLV objects)*

 -For each Queue:
    - Avg Queue length in a running window
    - Max Queue length in a running window (peak)
    - Current Queue length (?)
    - ASN of the oldest packet in the QUEUE?
    -Option Flag (weather there are optional TLV fields on that category)
        +(TLV objects)*

-Time source parent
    -ID
    -Avg clock drift (correction done) in a running window
    -Latest clock correction
    -Parent changes (counter of how many times I changed my time source
parent)
    -Option Flag (weather there are optional TLV fields on that category)
    +(TLV objects)*

-Option Flag (weather there are optional TLV fields in other categories)
   +(TLV objects)*

as regards to this:

"Finally, do you envision a generic mechanism whereby the PCE can turn
fields on/off, or triggered independently?"

I see it as CoAP Options, where a set of bytes can be used as "clever
bitmap" to tell what options are there, the parsing will decode option by
option and will read the fields. In that way any combination of fields is
supported.

would that work?
X

On Thu, Sep 5, 2013 at 4:03 PM, Thomas Watteyne
<[email-masked]>wrote:

> Xavi,
>
> Fantastic!
>
> I believe PDR for each link might be too long to fit in a packet. While
> the mote will most likely keep that information, we could move that to the
> Also, it might be good to be able to add arbitrary fields to each
> category: neighbor, queue, time source neighbor.
>
>>>> On Fri, Aug 30, 2013 at 10:45 AM, Qin Wang <[email-masked]>wrote:
>>>>
>>>>> Hi all,
>>>>>

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 5 Sep 2013 16:18:29 -0700

Fantastic. I guess something like that could work.
Thomas

On Thu, Sep 5, 2013 at 4:17 PM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

> On Thu, Sep 5, 2013 at 4:03 PM, Thomas Watteyne <
>>>> - I couldn't agree more with your suggestion to make it extensible.
>>>> This does mean that we will need to state somewhere that a device need to
>>>> ignore silently fields it does not understand.
>>>>
>>>> Thomas
>>>>
>>>>> Hello, I guess that flows are getting defined and I started to think
>>>>> on the contents of the messages on that flows. Not sure if this is the
>>>>> right time or I am going way far..
>>>>>
>>>>> The Report Flow: has to deal with the information that a node knows
>>>>> and has to be sent to the ME so the ME can compute the schedule among
>>>>> others. Here I list  the information that we can know in a mote and can be
>>>>> used at the ME to compute the schedule (complete please if I miss something)
>>>>>
>>>>> For each known neighbor:
>>>>>  -ID

---

From: Qin Wang <[email-masked]>
Date: Fri, 6 Sep 2013 21:40:51 +0800

Hi Xavi and Thomas,

I agree Xavi's the list. I also agree that it is very important to have a
generic mechanism whereby the PCE can turn fields on/off, or triggered
independently. I guess "Option Flag" is used to turn on/off. Correct?

Furthermore, I would like suggest to think the list as MIB, and leave
Report Packet configurable. For example, in the following list

 -ID

A specific PCE is not interested in Latest RSSI, then the PCE can use
Action Flow to configure its own Report Packet without the field, and don't
need the "Option Flag" in every report packet.

What do you think?

Qin

On Fri, Sep 6, 2013 at 7:18 AM, Thomas Watteyne
<[email-masked]>wrote:

>>>>> - the counters (numTx, etc) will only be present for neighbors the
>>>>> node has communicate with, so they should be optional in the packet.
>>>>> - you have focused on the topological information (which I think is
>>>>> the right one). It might be useful to gather other data related to

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 6 Sep 2013 10:50:04 -0400

Qin,
        I agree with the MIB approach. It would provide more scalability
for future versions too. I think the implementation cost and the added
processing time is worth it.

Diego

2013/9/6 Qin Wang <[email-masked]>:
> Furthermore, I would like suggest to think the list as MIB, and leave Report
> Packet configurable. For example, in the following list
>
>  -ID
> A specific PCE is not interested in Latest RSSI, then the PCE can use Action
> Flow to configure its own Report Packet without the field, and don't need
> the "Option Flag" in every report packet.
>
> What do you think?
>
> Qin
>
>
> On Fri, Sep 6, 2013 at 7:18 AM, Thomas Watteyne <[email-masked]>
> wrote:
>>
>> On Thu, Sep 5, 2013 at 4:17 PM, Xavier Vilajosana Guillen
>> <[email-masked]> wrote:
>>>
>>> agreed!
>>> So the fields become:
>>>
>>>
>>> For each known neighbor:
>>>  -ID
>>> <[email-masked]> wrote:
>>>>
>>>> Xavi,
>>>>
>>>> Fantastic!
>>>>
>>>> On Thu, Sep 5, 2013 at 12:47 PM, Xavier Vilajosana Guillen
>>>> <[email-masked]> wrote:
>>>>>
>>>>> Hi Thomas, Diego,
>>>>>
>>>>> On Thu, Sep 5, 2013 at 11:41 AM, Thomas Watteyne
>>>>> <[email-masked]> wrote:
>>>>>>
>>>>>> [renamed thread]
>>>>>>
>>>>>> Xavi,
>>>>>>
>>>>>> A few thoughts:
>>>>>> On Thu, Sep 5, 2013 at 11:15 AM, Xavier Vilajosana Guillen
>>>>>> <[email-masked]> wrote:
>>>>>>>
>>>>>>> on the contents of the messages on that flows. Not sure if this is the right
>>>>>>> ad-hoc/naive/other extensions of the reporting process. In that way we don't
>>>>>>> constraint the implementation of the scheduling alg. to that information.
>>>>>>>
>>>>>>> what do you think?
>>>>>>> X
>>>>>>>
>>>>>>>

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 6 Sep 2013 15:51:08 +0000

Hello Xavi:

At the call I mentioned we could use info on tracks and cells as well, probably on demand from the PCE.
For instance, the PCE could observe energy levels over some cells for  a while to make sure they are clean.

What do you think?
Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana Guillen
Sent: vendredi 6 septembre 2013 01:17
To: Thomas Watteyne
Cc: [email-masked]
Subject: Re: [6tsch] report flow contents

agreed!
So the fields become:

For each known neighbor:
 -ID

 -For each Queue:

-Time source parent
    -ID
    -Avg clock drift (correction done) in a running window
    -Latest clock correction
    -Parent changes (counter of how many times I changed my time source parent)
    -Option Flag (weather there are optional TLV fields on that category)
    +(TLV objects)*

as regards to this:

"Finally, do you envision a generic mechanism whereby the PCE can turn fields on/off, or triggered independently?"

I see it as CoAP Options, where a set of bytes can be used as "clever bitmap" to tell what options are there, the parsing will decode option by option and will read the fields. In that way any combination of fields is supported.

would that work?
X

On Thu, Sep 5, 2013 at 4:03 PM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
Xavi,

Fantastic!

I believe PDR for each link might be too long to fit in a packet. While the mote will most likely keep that information, we could move that to the query flow, i.e. it is available to the PCE on-demand.

Would you agree that the number of links in a bundle belongs to the neighbor? Of maybe we want a "bundle" category?

In queuing, it might be interesting to see the age of the different packets, to be able to monitor latency.

About LQI, there is no general consensus among vendors on what the definition is, or how exactly it is calculated. I would make it optional.

Also, it might be good to be able to add arbitrary fields to each category: neighbor, queue, time source neighbor.

Finally, do you envision a generic mechanism whereby the PCE can turn fields on/off, or triggered independently?

Thomas

On Thu, Sep 5, 2013 at 12:47 PM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Thomas, Diego,

I agree that LQI should be there as well. I update here the list with Thomas suggestions.

For each known neighbor:
 -ID

Other fields
    -Parent changes (counter of how many times I changed my time source parent)

Hope this makes sense.
cheers!
Xavi

On Thu, Sep 5, 2013 at 11:41 AM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
[renamed thread]

Xavi,

A few thoughts:
- the counters (numTx, etc) will only be present for neighbors the node has communicate with, so they should be optional in the packet.
- you have focused on the topological information (which I think is the right one). It might be useful to gather other data related to synchronization or queuing.
- I couldn't agree more with your suggestion to make it extensible. This does mean that we will need to state somewhere that a device need to ignore silently fields it does not understand.

Thomas

On Thu, Sep 5, 2013 at 11:15 AM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
Hello, I guess that flows are getting defined and I started to think on the contents of the messages on that flows. Not sure if this is the right time or I am going way far..

ME-6TOP - Query Flow
ME-6TOP - Action Flow

6TOP - ME - Report Flow
6TOP - ME - Event Flow

The Report Flow: has to deal with the information that a node knows and has to be sent to the ME so the ME can compute the schedule among others. Here I list  the information that we can know in a mote and can be used at the ME to compute the schedule (complete please if I miss something)

For each known neighbor:
 -ID

Other fields

Then we need to have some TLV like objects that can be used for ad-hoc/naive/other extensions of the reporting process. In that way we don't constraint the implementation of the scheduling alg. to that information.

what do you think?
X

On Fri, Aug 30, 2013 at 10:45 AM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

In this thread, we will continue the discussion about Confirmation message. Here is some background information.

Context: e.g.

IMHO, different control flow may have different requirement for confirmation message.
    (1) Action Flow, needs a App-level confirmation, like Succ/Fail
    (2) Query Flow, automatically has the confirmation, i.e. the message packet corresponding to a specific query.
    (3) Report Flow and Event Flow, option (1)-(3) are OK, but I prefer option (1) and (3), i.e. the confirmation message is an option, but if a confirmation message is needed, it should be App-level Ack, instead of transport layer confirmation, which will give 6top more flexibility.

What do you think?

Thanks
Qin

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

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

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

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

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 6 Sep 2013 10:08:51 -0700

Xavi,

Maybe if could be interesting to keep those idea in a temporary
"scratchpad". I was thinking a page on the
https://bitbucket.org/6tsch/meetings/wiki/Home wiki.

Thomas

On Fri, Sep 6, 2013 at 8:51 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Xavi:****
>
> ** **
>
> At the call I mentioned we could use info on tracks and cells as well,
> probably on demand from the PCE.****
>
> For instance, the PCE could observe energy levels over some cells for  a
> while to make sure they are clean.****
>
> ** **
>
> What do you think?****
>
> Pascal****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Xavier Vilajosana Guillen
> *Sent:* vendredi 6 septembre 2013 01:17
> *To:* Thomas Watteyne
> *Cc:* [email-masked]
> *Subject:* Re: [6tsch] report flow contents****
>
> ** **
>
> agreed!****
>
> So the fields become:****
>
> ** **
>
> ** **
>
> For each known neighbor:****
>
>  -ID****
>
>  -AVG RSSI in a running window****
>
>  -Latest RSSI****
>
>  -AVG LQI in a running window [optional]****
>
>  -Latest LQI [optional]****
>
> ****
>  -Num ACK packets (option in case there is communication with that
> neighbor)****
>
> ****
>  -Last ASN when it heart about that neighbor ****
>
>  -Bundle: Num links in the Schedule to that neighbor****
>
>       -PDR per link [Optional -- or maybe best and worst PDR only]****
>
>  ****
>
>  -Option Flag (weather there are optional TLV fields on that category)****
>
>    +(TLV objects)* ****
>
> ** **
>
>  -For each Queue:****
>
>     - Avg Queue length in a running window****
>
>     - Max Queue length in a running window (peak)****
>
>     - Current Queue length (?)****
>
>     - ASN of the oldest packet in the QUEUE?****
>
>     -Option Flag (weather there are optional TLV fields on that category)*
> ***
>
>         +(TLV objects)* ****
>
> ** **
>
> -Time source parent****
>
>     -ID****
>
>     -Avg clock drift (correction done) in a running window****
>
>     -Latest clock correction****
>
> parent)****
>     -Option Flag (weather there are optional TLV fields on that category)*
> ***
>
>     +(TLV objects)* ****
>
> ** **
>
> -Option Flag (weather there are optional TLV fields in other categories)**
> **
>
>    +(TLV objects)* ****
>
> ** **
>
> as regards to this:****
>
> ** **
>
> fields on/off, or triggered independently?"****
>
> ** **
>
> supported.****
> ** **
> would that work?****
> X****
> ** **
> [email-masked]> wrote:****
>
> Xavi,****
>
> ** **
>
> Fantastic!****
>
> ** **
>
> query flow, i.e. it is available to the PCE on-demand.****
>
> ** **
>
> neighbor? Of maybe we want a "bundle" category?****
>
> ** **
>
> packets, to be able to monitor latency.****
>
> ** **
>
> definition is, or how exactly it is calculated. I would make it optional.*
> ***
>
> ** **
>
> category: neighbor, queue, time source neighbor.****
>
> ** **
>
> fields on/off, or triggered independently?****
>
> ** **
>
> Thomas****
>
> ** **
>
> [email-masked]> wrote:****
>
> Hi Thomas, Diego,****
>
> ** **
>
> Thomas suggestions. ****
> ** **
> For each known neighbor:****
>
>  -ID****
>
>  -AVG RSSI in a running window****
>
>  -Latest RSSI****
>
>  -AVG LQI in a running window****
>
>  -Latest LQI****
>
> ****
>  -Num ACK packets (option in case there is communication with that
> neighbor)****
>
> ****
>  -Last ASN when it heart about that neighbor ****
>
> ** **
>
> Other fields****
>
>  -Num links in the Schedule to that neighbor****
>
>     -For each link PDR****
>
>  -For each Queue:****
>
>     - Avg Queue length in a running window****
>
>     - Max Queue length in a running window (peak)****
>
>     - Current Queue length (?)****
>
> -Time source parent****
>
>     -ID****
>
>     -Avg clock drift (correction done) in a running window****
>
>     -Latest clock correction****
>
> parent)****
> ** **
> -Option Flag (weather there are optional TLV fields)****
>
>    +(TLV objects)* ****
>
> ** **
>
> ** **
>
> Hope this makes sense.****
>
> cheers!
> Xavi****
>
> ** **
>
> [email-masked]> wrote:****
>
> *[renamed thread]*****
>
> ** **
>
> Xavi,****
>
> ** **
>
> A few thoughts:****
>
> has communicate with, so they should be optional in the packet.****
>
> synchronization or queuing.****
>
> silently fields it does not understand.****
>
> ** **
>
> Thomas****
>
> ** **
>
> [email-masked]> wrote:****
>
> time or I am going way far..****
>
> ** **
>
> According to the previous discussion I assume that the five flows are:****
>
> ** **
>
> ME-6TOP - Query Flow****
>
> ME-6TOP - Action Flow****
>
> ** **
>
> 6TOP - ME - Report Flow****
>
> 6TOP - ME - Event Flow****
>
> 6TOP - ME - Request BW Flow****
>
> ** **
>
> ****
> ** **
> the ME to compute the schedule (complete please if I miss something)****
>
> ** **
>
> For each known neighbor:****
>
>  -ID****
>
>  -AVG RSSI in a running window****
>
>  -Latest RSSI****
>
>  -Num TX packets****
>
>  -Num ACK packets****
>
>  -Num RX packets****
>
>  -Last ASN when it heart about that neighbor ****
>
> ** **
>
> Other fields****
>
>  -Num links in the Schedule to that neighbor****
>
>     -For each link PDR****
>
>  ****
>
>  ****
>
> information.****
> ** **
> what do you think?****
> X****
> ** **
> On Fri, Aug 30, 2013 at 10:45 AM, Qin Wang <[email-masked]> wrote:**
> **
>
>   Hi all,****
>
> ** **
>
> message. Here is some background information.****
>
> ** **
>
> Context: e.g.****
>
>     - node sends a report and want to know if the report is accepted., ***
> *
>
> ****
> Options:****
>    (1) Nothing****
>    (2) Rely on transport mechanism (e.g. confirmable CoAP message)****
>
>    (3) App-level ACK type****
>
>    (4) Use different flow (i.e. action flow)****
>
> ** **
>
> confirmation message.****
>
>     (1) Action Flow, needs a App-level confirmation, like Succ/Fail****
>
> packet corresponding to a specific query.****
>
> transport layer confirmation, which will give 6top more flexibility.****
>
> ** **
>
> What do you think?****
>
> ** **
>
> Thanks****
>
> Qin****
>
>     ****
>
> ** **
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ** **
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>
> ** **
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Fri, 6 Sep 2013 10:43:22 -0700

Hi Pascal, it is a good idea!

I will collect that information and as Thomas put it at the wiki so we do
not lose it.

:-)
X

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Fri, 6 Sep 2013 17:01:29 -0700

Hi,
I created the scratchpad section in the wiki to keep ideas
https://bitbucket.org/6tsch/meetings/wiki/Home

and added the flow content information here.

https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents

have a nice weekend!
X

On Fri, Sep 6, 2013 at 10:43 AM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Xavier Vilajosana Guillen
>>  -Num TX packets (option in case there is communication with that
>> neighbor)****
>>
>>  -Num RX packets (option in case there is communication with that
>> neighbor)****
>>
>> -Option Flag (weather there are optional TLV fields in other categories)*
>> ***
>>
>>    +(TLV objects)* ****
>>
>> ** **
>>
>> as regards to this:****
>>
>> ** **
>>
>>  -Num TX packets (option in case there is communication with that
>> neighbor)****
>>
>>  -Num RX packets (option in case there is communication with that
>> neighbor)****
>>
>> On Fri, Aug 30, 2013 at 10:45 AM, Qin Wang <[email-masked]> wrote:*
>> ***
>>
>>   Hi all,****
>>
>> ** **
>>
>>     - node sends a report and want to know if the report is accepted., **
>> **
>>

---

From: Thomas Watteyne <[email-masked]>
Date: Sat, 7 Sep 2013 10:43:05 -0700

Xavi,
Great, thanks!
Thomas

On Fri, Sep 6, 2013 at 5:01 PM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

>>> I'd like to start defining the content of the messages in the Report
>>> Flow:****
>>>
>>> ** **
>>>
>>>     - node sends a report and want to know if the report is accepted., *
>>> ***
>>>
>>>     - ME sends a action request and want to know if/when the action
>>> taken.****
>>>
>>> Options:****
>>>
>>>    (1) Nothing****
>>>

---

From: <[email-masked]>
Date: Wed, 11 Sep 2013 14:18:33 +0000

Dear All,
In the following, I listed the performance metrics reported to the Network/System Manager in WirelessHART and ISA100.11a.
Some reports still need be added, for example the path failure alerts in ISA100.11a.
Pouria

WirelessHART performance metrics
In WirelessHART[1] network the statistics and events are reported to the Network Manager (act like PCE in 6TiSCH) through the following commands:

  1.  Report "Device Health"
This report is sent periodically toward the Network Manager. The report summaries the communication statistics of a device.
Byte

Format

Description

0-1

Unsigned-16

Number of packets generated by this device since last report

2-3

Unsigned-16

Number of packets terminated by this device since last report

4

Unsigned-8

Number of Data-Link Layer MAC MIC failures detected

5

Unsigned-8

Number of Network Layer (Session) MIC failures detected

6

Enum-8

Power Status

7

Unsigned-8

Number of CRC Errors detected

  1.  Report "Neighbor Health List"

This report is sent periodically toward the Network Manager. The report includes the statistics of linked neighbors.
Byte

Format

Description

0

Unsigned-8

Neighbor table index

1

Unsigned-8

Number of Neighbor entries read

2

Unsigned-8

Total number of neighbors

3-4

Unsigned-16

Nickname of neighbor

5

Bit-8

Neighbor Flags

6

Signed-8

Mean RSL (Receive Signal Level in dBm) since last report

7-8

Unsigned-16

Number of Packets transmitted to this neighbor

9-10

Unsigned-16

Number of Packets received from this neighbor

11-12

Unsigned-16

Packets received from this neighbor

13-...

Number of entries based on response byte 1

  1.  Report "Neighbor Signal Levels"

This report is sent periodically toward the Network Manager. The report includes the statistics of discovered (but not linked) neighbors. These neighbors might be discovered when a device has heard the neighbor communication in the discovery links. A device that wish to join a network, send a join request to the Network manager, including this report.
Byte

Format

Description

0

Unsigned-8

Neighbor table index

1

Unsigned-8

Number of Neighbor entries read

2

Unsigned-8

Total number of neighbors

3-4

Unsigned-16

Nickname of neighbor

5

Signed-8

RSL of neighbor in dB

6-8

Repeats (as needed) based on response byte 1

  1.  Alarm "Path Down"

The alarm is sent upon detecting a path failure.

Byte

Format

Description

0-1

Unsigned-16

Nickname of neighbor to which path failure was detected

  1.  Alarm "Source Route Failed"

This alarm is sent upon detecting a source route failure.

Byte

Format

Description

0-1

Unsigned-16

Nickname of unreachable neighbor in the source route

2-5

Unsigned-32

Network-Layer MIC (i.e., the MIC generated using the session key) from the NPDU that failed routing

  1.  Alarm "Graph Route Failed"

This alarm is sent upon detecting a graph route failure.

Byte

Format

Description

0-1

Unsigned-16

Graph Id of the failed route

ISA100.11a performance metric
In ISA100.11a[2], the L2 performance metrics are reported to the System Manager (act like PCE in 6TiSCH) and can be classified into (1) DL_Connectivity alert and (2) NeighborDiscovery alert.

  1.  DL_Connectivity alert
The DL_connectivity alert can be classified into (a) Per-neighbor reports and (b) Per-channel reports.

     *   Per-neighbor report

Per-neighbor reports are the  performance metrics about the neighbors connection and are reported to the System Manager. These statistics are accumulated in the "dlmo.NeighborDiag" attribute, for each neighbor. This report is similar to "Neighbor Health List" report in WirelessHART.

Each node in ISA100.11a might be asked to report the following statistics about its neighbor:

Octets

Format

Description

1

Signed-8

RSSI (level)

1

Unsigned-8

RSQI (level)

1-2

ExtDLUint

RxDPDU(count): Number of valid Packets received from this neighbor

1-2

ExtDLUint

TxSuccessful (count):Count of successful unicast transmissions to the neighbor

1-2

ExtDLUint

TxFailed (count): Number of unicast transmission, without  getting any ACK or NACK

1-2

ExtDLUint

TxCCA_Backoff (count): Number of unicast transmission aborted due to CCA

1-2

ExtDLUint

TxNACK (count): Number of NACKs received

2

Signed-16

ClockSigma (level): A rough estimate of standard deviation of clock corrections

     *   Per-channel report
In addition, in ISA100.11a, several performance metrics are reported based on channel for all neighbors to the System Manager. These statistics are accumulated in the "dlmo.ChannelDiag" attribute. This report is similar to "Device Health" report in WirelessHART.

Byte

Format

Description

0-2

Unsigned-16

Count (Number of attempted unicast transmissions for all channels)

3

Integer-8

 (Percentage of time transmissions on channel 0 did not receive an ACK)

4

Integer-8

 (Percentage of time transmissions on channel 0 aborted due to CCA)

...

33

Integer-8

 (Percentage of time transmissions on channel 15 did not receive an ACK)

34

Integer-8

 (Percentage of time transmissions on channel 15 aborted due to CCA)

  1.  NeighborDiscovery alert
In ISA100.11a, each node sends a report, including a list of candidate (overheard) neighbors, to the System Manager to make a potential new routing decisions. The "dlmo.Candidates" attributed is used to store those information in each node in the L2. This report is similar to the "Neighbor Signal Levels" report in WirelessHART.

Octets

Format

Description

1

Unsigned-8

N (count of discovered neighbors)

0-2

ExtDlUint

 address

0-1

Signed-8

0-1

Unsigned-8

...

0-2

ExtDlUint

 address

0-1

Signed-8

0-1

Unsigned-8

References

1.       IEC 62591: Industrial Communication Networks - Wireless Communication Network and Communication Profiles - WirelessHART.

2.       IEC 62734: Industrial communication networks - Fieldbus specifications - Wireless systems for industrial automation: process control and related applications - ISA100.11a.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Saturday, September 07, 2013 7:43 PM
To: Xavi Vilajosana
Cc: Pascal Thubert (pthubert); [email-masked]
Subject: Re: [6tsch] report flow contents

Xavi,
Great, thanks!
Thomas

On Fri, Sep 6, 2013 at 5:01 PM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
I created the scratchpad section in the wiki to keep ideas
https://bitbucket.org/6tsch/meetings/wiki/Home

On Fri, Sep 6, 2013 at 10:43 AM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pascal, it is a good idea!
I will collect that information and as Thomas put it at the wiki so we do not lose it.

:-)
X

On Fri, Sep 6, 2013 at 8:51 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Xavi:

What do you think?
Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Xavier Vilajosana Guillen
Sent: vendredi 6 septembre 2013 01:17
To: Thomas Watteyne
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tsch] report flow contents

agreed!
So the fields become:

For each known neighbor:
 -ID

 -For each Queue:

-Time source parent
    -ID

as regards to this:

would that work?
X

Fantastic!

Thomas

For each known neighbor:
 -ID

Other fields

Hope this makes sense.
cheers!
Xavi

Xavi,

A few thoughts:

Thomas

ME-6TOP - Query Flow
ME-6TOP - Action Flow

6TOP - ME - Report Flow
6TOP - ME - Event Flow

For each known neighbor:
 -ID

Other fields

what do you think?
X

Context: e.g.

What do you think?

Thanks
Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 11 Sep 2013 09:58:56 -0700

Pouria,

Wonderful list.

Your document clearly highlights that (1) the "report" flows both in
WirelessHART and ISA100.11a are strictly periodic and (1) they have a fixed
format. From what we have discussed so far, the solutions we are developing
is different in the following ways:

   - 6TiSCH offers a mechanism allowing the PCE to configure what data it
   want to receive, and configure the trigger for a node to generate from data.
   - 6TiSCH offers a mechanism allowing the PCE to query the data, on top
   of having the nodes push the information
   - In 6TiSCH, the format of the payload is not fixed. In particular, it
   is possible to add application-specific fields, allowing for extensions.
   - In 6TiSCH, the transport (CoAP?) and formatting (CBOR?) are
   IETF-friendly and integrate well in the IPv6 stack and associated mechanisms

Did I get that right?

A couple of questions:

   - the WirelessHART "alarms" correspond to a 6TiSCH "events". Yet, I
   suppose that a "source route failed" and "graph route failed" are out of
   scope of 6TiSCH, but rather part of RPL. I would expect those to the ICMPv6
   messages. Thoughts?
   - About the per-channel report, I assume this is "per frequency", right?
   Is a channel report generated for each neighbor?
   - When comparing your list to *Xavi*'s
   https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents:
      - we might want to add a "numNACK" counter to the neighbor information
      - we might want to keep timing statistics for all neighbors, not just
      time source parents. That is, when I receive a packet from a
neighbor which
      is not my time source neighbor, I do not change my clock, but I
still know
      the timing error.

Thomas

On Wed, Sep 11, 2013 at 7:18 AM, <[email-masked]> wrote:

>  Dear All,****
>
> In the following, I listed the performance metrics reported to the
> Network/System Manager in WirelessHART and ISA100.11a.****
>
> Some reports still need be added, for example the path failure alerts in
> ISA100.11a.****
>
> Pouria****
>
> ** **
>
> *WirelessHART performance metrics*
>
> In WirelessHART[1] network the statistics and events are reported to the
> Network Manager (act like PCE in 6TiSCH) through the following commands:**
> **
>
>    1. Report “Device Health” ****
>
>  This report is sent periodically toward the Network Manager. The report
> summaries the communication statistics of a device.****
>
> Byte****
>
> Format****
>
> Description****
>
> 0-1****
>
> Unsigned-16****
>
> Number of packets generated by this device since last report****
>
> 2-3****
>
> Unsigned-16****
>
> Number of packets terminated by this device since last report****
>
> 4****
>
> Unsigned-8****
>
> Number of Data-Link Layer MAC MIC failures detected****
>
> 5****
>
> Unsigned-8****
>
> Number of Network Layer (Session) MIC failures detected****
>
> 6****
>
> Enum-8****
>
> Power Status****
>
> 7****
>
> Unsigned-8****
>
> Number of CRC Errors detected****
>
> ** **
>
>    1. Report “Neighbor Health List” ****
>
>  This report is sent periodically toward the Network Manager. The report
> includes the statistics of linked neighbors.****
>
> Byte****
>
> Format****
>
> Description****
>
> 0****
>
> Unsigned-8****
>
> Neighbor table index****
>
> 1****
>
> Unsigned-8****
>
> Number of Neighbor entries read****
>
> 2****
>
> Unsigned-8****
>
> Total number of neighbors****
>
> 3-4****
>
> Unsigned-16****
>
> Nickname of neighbor****
>
> 5****
>
> Bit-8****
>
> Neighbor Flags****
>
> 6****
>
> Signed-8****
>
> Mean RSL (Receive Signal Level in dBm) since last report****
>
> 7-8****
>
> Unsigned-16****
>
> Number of Packets transmitted to this neighbor****
>
> 9-10****
>
> Unsigned-16****
>
> Number of Packets received from this neighbor****
>
> 11-12****
>
> Unsigned-16****
>
> Packets received from this neighbor****
>
> 13-…****
>
> ** **
>
> Number of entries based on response byte 1****
>
> ** **
>
>    1. Report “Neighbor Signal Levels”****
>
>  This report is sent periodically toward the Network Manager. The report
> includes the statistics of discovered (but not linked) neighbors. These
> neighbors might be discovered when a device has heard the neighbor
> communication in the discovery links. A device that wish to join a network,
> send a join request to the Network manager, including this report.****
>
> Byte****
>
> Format****
>
> Description****
>
> 0****
>
> Unsigned-8****
>
> Neighbor table index****
>
> 1****
>
> Unsigned-8****
>
> Number of Neighbor entries read****
>
> 2****
>
> Unsigned-8****
>
> Total number of neighbors****
>
> 3-4****
>
> Unsigned-16****
>
> Nickname of neighbor****
>
> 5****
>
> Signed-8****
>
> RSL of neighbor in dB****
>
> 6-8****
>
> ** **
>
> Repeats (as needed) based on response byte 1****
>
> ** **
>
>    1. Alarm “Path Down” ****
>
>  The alarm is sent upon detecting a path failure. ****
>
> Byte****
>
> Format****
>
> Description****
>
> 0-1****
>
> Unsigned-16****
>
> Nickname of neighbor to which path failure was detected****
>
> ** **
>
>    1. Alarm "Source Route Failed"****
>
>  This alarm is sent upon detecting a source route failure.****
>
> Byte****
>
> Format****
>
> Description****
>
> 0-1****
>
> Unsigned-16****
>
> Nickname of unreachable neighbor in the source route****
>
> 2-5****
>
> Unsigned-32****
>
> Network-Layer MIC (i.e., the MIC generated using the session key) from the
> NPDU that failed routing****
>
> ** **
>
>    1. Alarm "Graph Route Failed"****
>
>  This alarm is sent upon detecting a graph route failure.****
>
> Byte****
>
> Format****
>
> Description****
>
> 0-1****
>
> Unsigned-16****
>
> Graph Id of the failed route****
>
> ** **
>
>  ** **
>
> *ISA100.11a performance metric*
>
> In ISA100.11a[2], the L2 performance metrics are reported to the System
> Manager (act like PCE in 6TiSCH) and can be classified into (1)
> DL_Connectivity alert and (2) NeighborDiscovery alert.****
>
>    1. DL_Connectivity alert****
>
>  The DL_connectivity alert can be classified into (a) Per-neighbor
> reports and (b) Per-channel reports. ****
>
>     - *Per-neighbor report*
>
>  Per-neighbor reports are the  performance metrics about the neighbors
> connection and are reported to the System Manager. These statistics are
> accumulated in the “dlmo.NeighborDiag” attribute, for each neighbor. This
> report is similar to “Neighbor Health List” report in WirelessHART. ****
>
> Each node in ISA100.11a might be asked to report the following statistics
> about its neighbor:****
>
> ** **
>
> Octets****
>
> Format****
>
> Description****
>
> 1****
>
> Signed-8****
>
> RSSI (level)****
>
> 1****
>
> Unsigned-8****
>
> RSQI (level)****
>
> 1-2****
>
> ExtDLUint****
>
> RxDPDU(count): Number of valid Packets received from this neighbor ****
>
> 1-2****
>
> ExtDLUint****
>
> TxSuccessful (count):Count of successful unicast transmissions to the
> neighbor ****
>
> 1-2****
>
> ExtDLUint****
>
> TxFailed (count): Number of unicast transmission, without  getting any ACK
> or NACK****
>
> 1-2****
>
> ExtDLUint****
>
> TxCCA_Backoff (count): Number of unicast transmission aborted due to CCA**
> **
>
> 1-2****
>
> ExtDLUint****
>
> TxNACK (count): Number of NACKs received****
>
> 2****
>
> Signed-16****
>
> ClockSigma (level): A rough estimate of standard deviation of clock
> corrections****
>
> ** **
>
>     - *Per-channel report*
>
>  In addition, in ISA100.11a, several performance metrics are reported
> based on channel for all neighbors to the System Manager. These statistics
> are accumulated in the “dlmo.ChannelDiag” attribute. This report is similar
> to “Device Health” report in WirelessHART.****
>
> Byte****
>
> Format****
>
> Description****
>
> 0-2****
>
> Unsigned-16****
>
> Count (Number of attempted unicast transmissions for all channels)****
>
> 3****
>
> Integer-8****
>
> **** (Percentage of time transmissions on channel 0 did not receive an
> ACK)****
>
> 4****
>
> Integer-8****
>
> **** (Percentage of time transmissions on channel 0 aborted due to CCA)***
> *
>
> …****
>
> ** **
>
> ** **
>
> 33****
>
> Integer-8****
>
> **** (Percentage of time transmissions on channel 15 did not receive an
> ACK)****
>
> 34****
>
> Integer-8****
>
> **** (Percentage of time transmissions on channel 15 aborted due to CCA)**
> **
>
> ** **
>
>    1. NeighborDiscovery alert****
>
>  In ISA100.11a, each node sends a report, including a list of candidate
> (overheard) neighbors, to the System Manager to make a potential new
> routing decisions. The “dlmo.Candidates” attributed is used to store those
> information in each node in the L2. This report is similar to the “Neighbor
> Signal Levels” report in WirelessHART.****
>
> Octets****
>
> Format****
>
> Description****
>
> 1****
>
> Unsigned-8****
>
> N (count of discovered neighbors)****
>
> 0-2****
>
> ExtDlUint****
>
> **** address****
>
> 0-1****
>
> Signed-8****
>
> **** ****
>
> 0-1****
>
> Unsigned-8****
>
> ********
>
> …****
>
> ** **
>
> ** **
>
> 0-2****
>
> ExtDlUint****
>
> **** address****
>
> 0-1****
>
> Signed-8****
>
> **** ****
>
> 0-1****
>
> Unsigned-8****
>
> ********
>
> ** **
>
> * *
>
> *References*
>
> **1.       **IEC 62591: Industrial Communication Networks - Wireless
> Communication Network and Communication Profiles - WirelessHART.****
>
> ** **
>
> **2.       **IEC 62734: Industrial communication networks - Fieldbus
> specifications - Wireless systems for industrial automation: process
> control and related applications - ISA100.11a.****
>
> ** **
>
> ** **
>
> ** **
>
> Of *Thomas Watteyne
> *Sent:* Saturday, September 07, 2013 7:43 PM
> *To:* Xavi Vilajosana
> *Cc:* Pascal Thubert (pthubert); [email-masked]
> Great, thanks!****
> https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents****
>
> have a nice weekend!****
>
> X****
>
> ** **
>
> Hi Pascal, it is a good idea!****
>
> :-)****
> [email-masked]> wrote:****
>
>  Hello Xavi:****
>
>  ****
>

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Wed, 11 Sep 2013 11:54:22 -0700

Hi Thomas,

my 5 cents.
I agree on adding NACK information and timing differences with other than
time source parent neighbors. I will add to the wiki :-)

As regards to the differences of what we do at 6TiSCH and WHart or
ISA100.11a, our proposal is more flexible and has less cohesion with a cost
of increased complexity (e.g configurable data and reporting period). We
have to analyse carefully what are the implications in terms of protocol
complexity and implementation of that mechanism versus how often they would
be used. Could we maybe define some "templates" or default configurations
so using the 6TiSCH can be done without configuration overhead? Then
configuration can be used for those that are really interested on tuning
their system.

just thoughts..
X

On Wed, Sep 11, 2013 at 9:58 AM, Thomas Watteyne <[email-masked]

>    - About the per-channel report, I assume this is "per frequency",
>    right? Is a channel report generated for each neighbor?
>       - we might want to keep timing statistics for all neighbors, not
>       just time source parents. That is, when I receive a packet from a neighbor
>       which is not my time source neighbor, I do not change my clock, but I still
>       know the timing error.
>
> Thomas
>
>> Network Manager (act like PCE in 6TiSCH) through the following commands:*
>> ***
>>
>> Network-Layer MIC (i.e., the MIC generated using the session key) from
>> the NPDU that failed routing****
>>
>> ** **
>>
>> TxFailed (count): Number of unicast transmission, without  getting any
>> ACK or NACK****
>>
>> 1-2****
>>
>> ExtDLUint****
>>
>> TxCCA_Backoff (count): Number of unicast transmission aborted due to CCA*
>> ***
>>
>> 1-2****
>>
>> ExtDLUint****
>>
>> **** (Percentage of time transmissions on channel 0 aborted due to CCA)**
>> **
>>
>> …****
>>
>> ** **
>>
>> ** **
>>
>> 33****
>>
>> Integer-8****
>>
>> **** (Percentage of time transmissions on channel 15 aborted due to CCA)*
>> ***
>>
>> ** **
>>
>> Behalf Of *Thomas Watteyne

---

From: <[email-masked]>
Date: Wed, 11 Sep 2013 20:44:52 +0000

Thomas,
I agree with you that "source route failed" and "graph route failed" are out of scope of 6TiSCH.
Regarding to you question about the per-channel report, I think they are based on each radio channel supported by the specification (channel 11-26 in 2.4GHz in IEEE 802.15.4), not channel offset. And a channel report generated for all neighbor.
Regarding to your first question, let me now explain more. I think both of these standard provide a mechanisms to make it possible for System/Network Manager to also read (pull) desired attributes (But not all the feature in 6TiSCH). For example in WirelessHART [1], by "Report Neighbor Health List" request, the network manager might mention the number of neighbors to be read in "Number of Neighbor entries read" field..
I think, ISA100.11a provides more mechanisms for System manager to get the desired attributes from the field devices. And the first two features that you mentioned might also be supported by ISA100.11a.
In ISA100.11a, three mechanisms are provided for reporting diagnostic information contained in dlmo.NeighborDiag (described in section 1 later) and dlmo.ChannelDiag (described in Section 2 later):

  1.  The health reports concentrator object (HRCO), can be configured to report any attribute in the DL on a periodic basis. dlmo.NeighborDiag entries (shown in Table 2) and dlmo.ChannelDiag (shown in Table 5) can be reported through that mechanism. Through the HRCO, the system manager can configure the device to report NeighborDiag periodically, such as every 30 minutes. Following each such report, on a per-entry basis, NeighborDiag counts shall be reset to zero. Levels shall use the current value as a starting point for the next period [2].
  2.  Diagnostic information can be retrieved at any time by the system manager, by reading the applicable attributes. The system manager can read (poll) NeighborDiag as a read-only attribute on a per-entry basis. As in an HRCO report, counts shall be reset to zero when read [2].
  3.  Diagnostic information can be reported by the DL on an exception basis, through the DL_Connectivity alert (Described in section 3(a)). The DL can additionally be configured, through the dlmo.AlertPolicy attribute (shown in Table 6), to report NeighborDiag information when diagnostic values exceed a threshold. Only the row triggering the alert is reported. No values are reset [2].

In ISA100.11a, the system manager establishes a DL communication relationship between a device and its neighbor by adding an entry to the device's dlmo.Neighbor attribute (see Table 1). Each such entry specifies a level of diagnostics to be collected, through the field dlmo.Neighbor[].DiagLevel. For each neighbor, diagnostics may be collected at a baseline level, or a detailed level including clock diagnostics [2]. This levels are described in Section 1.
Table 1. dlmo.Neighbor fields [2]
Field name

Field encoding

* Index (16-bit address of neighbor)

ExtDlUint (used as an index)

EUI64 (EUI-64 identifier of the neighbor)

Type: Unsigned64

...

...

DiagLevel (selection of neighbor diagnostics to collect)

Type: Unsigned2
Bit0 = 1 Collect link diagnostics
Bit1 = 1 Collect clock diagnostics

...

...

When the dlmo.Neighbor[].DiagLevel field is set for a particular neighbor, the DL shall create corresponding entries in the read-only attribute dlmo.NeighborDiag. NeighborDiag values are accumulated from the time that the dlmo.NeighborDiag entry is created [2].

1.       dlmo.NeighborDiag:
dlmo.NeighborDiag is an indexed OctetString collection that contains diagnostics for a set of neighbors. The attribute is read-only, with rows created as needed by the DL [2].
NeighborDiag entries are instantiated by the system manager, by setting dlmo.Neighbor[].DiagLevel bits to non-zero values. Iff (if and only if) Bit0=1, then summary diagnostics shall be collected for the neighbor, consolidated across all channels. Iff Bit1=1, then detailed clock diagnostics shall be collected for the neighbor, consolidated across all radio channels [2].
Table 2. dlmo.NeighborDiag fields [2]
Field name

Field encoding

* Index

Type: ExtDlUint (neighbor address, used as an index)

Summary

Type: OctetString (see Table 3)

ClockDetail

Type: OctetString (see Table 4)

Table 3. Diagnostic Summary OctetString fields [2]
Field name

Field encoding

RSSI (level)

Type: Integer8

RSQI (level)

Type: Unsigned8

RxDPDU (count)

Type: ExtDlUint

TxSuccessful (count)

Type: ExtDlUint

TxFailed (count)

Type: ExtDlUint

TxCCA_Backoff (count)

Type: ExtDlUint

TxNACK (count)

Type: ExtDlUint

ClockSigma (level)

Type: Integer16

Table 4. Diagnostic ClockDetail OctetString fields [2]
Field name

Field encoding

ClockBias (level, signed)

Type: Integer16

ClockCount (count)

Type: ExtDlUint

ClockTimeout (count)

Type: ExtDlUint

ClockOutliers (count)

Type: ExtDlUint

2.       dlmo.ChannelDiag:

dlmo.ChannelDiag is a read-only dynamic attribute that reports DPDU transmit failure rates on each radio channel supported by the specification. This enables the system manager to be aware of consistent connectivity problems on a per-channel basis, as a diagnostic for spectrum management in a subnet [2].
Two diagnostics are reported for each channel, each indicating a different type of failure.   indicates the percentage of time that unicast DPDU transmissions on channel N did not receive an ACK or a NACK.   indicates the percentage of time that unicast DPDU transmissions on channel N were aborted due to CCA. [2]
Table 5. dlmo.ChannelDiag fields
Field name

Field encoding

Type:Unsigned16

Type: Integer8

Type: Integer8

...

Type: Integer8

Type: Integer8

3.       Data link layer alerts

  1.  DL_Connectivity alert

DL performance diagnostics are accumulated in the attributes dlmo.NeighborDiag for per-neighbor diagnostics, and dlmo.ChannelDiag for per-channel diagnostics. Normally the system manager configures the HRCO to report these diagnostics periodically, and the DL automatically resets the diagnostic counters whenever these attributes are so reported. Between such reports, diagnostics may indicate a problem that needs to be reported to the system manager immediately. The DL_Connectivity alert provides the mechanism for the DL to report such issues, and the dlmo.AlertPolicy attribute enables the system manager to set thresholds for such reporting [2].

The attribute dlmo.AlertPolicy enables/disables the DL_Connectivity alert and provides thresholds to control whether alerts are reported. dlmo.AlertPolicy is an OctetString containing fields as shown in Table 6 [2].
Table 6. dlmo.AlertPolicy fields

Field name

Field scalar type

Descriptor (Enables or disabled the DL_Connectivity alert.)

Type Alert report descriptor

NeiMinUnicast (Minimum number of unicast transactions needed for a neighbor report.)

Type: ExtDlUint

NeiErrThresh (Report neighbor diagnostic if the percentage error rate reaches this threshold )

Type: Unsigned8

ChanMinUnicast (Minimum number of unicast transactions on a channel needed as a pre-condition for triggering an alert.)

Type: ExtDlUint

NoAckThresh (Report ChannelDiag if a NoAck value is greater than this threshold)

Type: Unsigned8

CCABackoffThresh (Report ChannelDiag if a CCABackoff value is greater than this threshold)

Type: Unsigned8

  1.  NeighborDiscovery alert
The NeighborDiscovery alert provides a mechanism for the DL to report the contents of the OctetString in dlmo.Candidates attribute (see Table 7).
The neighbors in the dlmo.Neighbor attribute are set by the system manager, not by the device itself. The DL autonomously builds a list of candidate neighbors in the dlmo.Candidates attribute. This list is then forwarded to the system manager. The system manager considers the radio connectivity that is reported in dlmo.Candidates, but may also consider other criteria such as resource constraints, historical performance, or subnet topology [2].
Table 7. dlmo.Candidates OctetString fields
Field name

Field encoding

Type: Unsigned8

Neighbor1 (16-bit address of first candidate)

Type: ExtDlUint

RSSI1 (radio signal quality of first candidate)

Type: Integer8

RSQI1 (radio signal quality of first candidate)

Type: Unsigned8

etc...

NeighborN (16-bit address of Nth candidate)

Type: ExtDlUint

RSSIN (radio signal quality of Nth candidate)

Type: Integer8

RSQIN (radio signal quality of Nth candidate)

Type: Unsigned8

References

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana Guillen
Sent: Wednesday, September 11, 2013 8:54 PM
To: Thomas Watteyne
Cc: 6TSCH
Subject: Re: [6tsch] report flow contents

Hi Thomas,
my 5 cents.
I agree on adding NACK information and timing differences with other than time source parent neighbors. I will add to the wiki :-)
As regards to the differences of what we do at 6TiSCH and WHart or ISA100.11a, our proposal is more flexible and has less cohesion with a cost of increased complexity (e.g configurable data and reporting period). We have to analyse carefully what are the implications in terms of protocol complexity and implementation of that mechanism versus how often they would be used. Could we maybe define some "templates" or default configurations so using the 6TiSCH can be done without configuration overhead? Then configuration can be used for those that are really interested on tuning their system.
just thoughts..
X

On Wed, Sep 11, 2013 at 9:58 AM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
Pouria,

Wonderful list.

Your document clearly highlights that (1) the "report" flows both in WirelessHART and ISA100.11a are strictly periodic and (1) they have a fixed format. From what we have discussed so far, the solutions we are developing is different in the following ways:

  *   6TiSCH offers a mechanism allowing the PCE to configure what data it want to receive, and configure the trigger for a node to generate from data.
  *   6TiSCH offers a mechanism allowing the PCE to query the data, on top of having the nodes push the information
  *   In 6TiSCH, the format of the payload is not fixed. In particular, it is possible to add application-specific fields, allowing for extensions.
  *   In 6TiSCH, the transport (CoAP?) and formatting (CBOR?) are IETF-friendly and integrate well in the IPv6 stack and associated mechanisms
Did I get that right?

A couple of questions:

  *   the WirelessHART "alarms" correspond to a 6TiSCH "events". Yet, I suppose that a "source route failed" and "graph route failed" are out of scope of 6TiSCH, but rather part of RPL. I would expect those to the ICMPv6 messages. Thoughts?
  *   About the per-channel report, I assume this is "per frequency", right? Is a channel report generated for each neighbor?
  *   When comparing your list to Xavi's https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents:

     *   we might want to add a "numNACK" counter to the neighbor information
     *   we might want to keep timing statistics for all neighbors, not just time source parents. That is, when I receive a packet from a neighbor which is not my time source neighbor, I do not change my clock, but I still know the timing error.
Thomas

On Wed, Sep 11, 2013 at 7:18 AM, <[email-masked]<mailto:[email-masked]>> wrote:

Dear All,

Pouria

Byte

Format

Description

0-1

Unsigned-16

2-3

Unsigned-16

4

Unsigned-8

5

Unsigned-8

6

Enum-8

Power Status

7

Unsigned-8

Byte

Format

Description

0

Unsigned-8

Neighbor table index

1

Unsigned-8

2

Unsigned-8

3-4

Unsigned-16

Nickname of neighbor

5

Bit-8

Neighbor Flags

6

Signed-8

7-8

Unsigned-16

9-10

Unsigned-16

11-12

Unsigned-16

13-...

Byte

Format

Description

0

Unsigned-8

Neighbor table index

1

Unsigned-8

2

Unsigned-8

3-4

Unsigned-16

Nickname of neighbor

5

Signed-8

RSL of neighbor in dB

6-8

  1.  Alarm "Path Down"

Byte

Format

Description

0-1

Unsigned-16

Byte

Format

Description

0-1

Unsigned-16

2-5

Unsigned-32

Byte

Format

Description

0-1

Unsigned-16

  1.  DL_Connectivity alert

     *   Per-neighbor report

Octets

Format

Description

1

Signed-8

RSSI (level)

1

Unsigned-8

RSQI (level)

1-2

ExtDLUint

1-2

ExtDLUint

1-2

ExtDLUint

1-2

ExtDLUint

1-2

ExtDLUint

2

Signed-16

     *   Per-channel report

Byte

Format

Description

0-2

Unsigned-16

3

Integer-8

4

Integer-8

...

33

Integer-8

34

Integer-8

Octets

Format

Description

1

Unsigned-8

0-2

ExtDlUint

address

0-1

Signed-8

0-1

Unsigned-8

...

0-2

ExtDlUint

address

0-1

Signed-8

0-1

Unsigned-8

References

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Thomas Watteyne
Sent: Saturday, September 07, 2013 7:43 PM
To: Xavi Vilajosana
Cc: Pascal Thubert (pthubert); [email-masked]<mailto:[email-masked]>
Subject: Re: [6tsch] report flow contents

Xavi,

Great, thanks!

Thomas

Hi,

have a nice weekend!

X

:-)

X

Hello Xavi:

What do you think?

Pascal

agreed!

So the fields become:

For each known neighbor:

 -ID

 -Latest RSSI

 -Latest LQI [optional]

   +(TLV objects)*

 -For each Queue:

        +(TLV objects)*

-Time source parent

    -ID

    -Latest clock correction

    +(TLV objects)*

   +(TLV objects)*

as regards to this:

would that work?

X

Xavi,

Fantastic!

Thomas

Hi Thomas, Diego,

For each known neighbor:

 -ID

 -Latest RSSI

 -Latest LQI

Other fields

    -For each link PDR

 -For each Queue:

-Time source parent

    -ID

    -Latest clock correction

   +(TLV objects)*

Hope this makes sense.

cheers!
Xavi

[renamed thread]

Xavi,

A few thoughts:

Thomas

ME-6TOP - Query Flow

ME-6TOP - Action Flow

6TOP - ME - Report Flow

6TOP - ME - Event Flow

For each known neighbor:

 -ID

 -Latest RSSI

 -Num TX packets

 -Num ACK packets

 -Num RX packets

Other fields

    -For each link PDR

what do you think?

X

Hi all,

Context: e.g.

Options:

   (1) Nothing

   (3) App-level ACK type

What do you think?

Thanks

Qin

---

From: "Alfredo Grieco" <[email-masked]>
Date: Thu, 12 Sep 2013 09:34:06 +0200

Hi All,
 
Do you think is it feasible to add a bit/flag that allows some form of
in-network processing ? 
 
This would be very useful to distributed/decentralized scheduling techniques
and should not cost that much.
 
Any thoughts is welcome.
 
Cheers
 
Alfredo
 
Da: [email-masked] [mailto:[email-masked]] Per conto di
[email-masked]
Inviato: Wednesday, September 11, 2013 10:45 PM
A: [email-masked]; [email-masked]
Cc: [email-masked]
Oggetto: Re: [6tsch] report flow contents
 
Thomas,
I agree with you that "source route failed" and "graph route failed" are out
of scope of 6TiSCH.
Regarding to you question about the per-channel report, I think they are
based on each radio channel supported by the specification (channel 11-26 in
2.4GHz in IEEE 802.15.4), not channel offset. And a channel report generated
for all neighbor.
Regarding to your first question, let me now explain more. I think both of
these standard provide a mechanisms to make it possible for System/Network
Manager to also read (pull) desired attributes (But not all the feature in
6TiSCH). For example in WirelessHART [1], by "Report Neighbor Health List"
request, the network manager might mention the number of neighbors to be
read in "Number of Neighbor entries read" field.. 
I think, ISA100.11a provides more mechanisms for System manager to get the
desired attributes from the field devices. And the first two features that
you mentioned might also be supported by ISA100.11a.
In ISA100.11a, three mechanisms are provided for reporting diagnostic
information contained in dlmo.NeighborDiag (described in section 1 later)
and dlmo.ChannelDiag (described in Section 2 later):
I.	The health reports concentrator object (HRCO), can be configured to
report any attribute in the DL on a periodic basis. dlmo.NeighborDiag
entries (shown in Table 2) and dlmo.ChannelDiag (shown in Table 5) can be
reported through that mechanism. Through the HRCO, the system manager can
configure the device to report NeighborDiag periodically, such as every 30
minutes. Following each such report, on a per-entry basis, NeighborDiag
counts shall be reset to zero. Levels shall use the current value as a
starting point for the next period [2].
II.	Diagnostic information can be retrieved at any time by the system
manager, by reading the applicable attributes. The system manager can read
(poll) NeighborDiag as a read-only attribute on a per-entry basis. As in an
HRCO report, counts shall be reset to zero when read [2].
III.	Diagnostic information can be reported by the DL on an exception
basis, through the DL_Connectivity alert (Described in section 3(a)). The DL
can additionally be configured, through the dlmo.AlertPolicy attribute
(shown in Table 6), to report NeighborDiag information when diagnostic
values exceed a threshold. Only the row triggering the alert is reported. No
values are reset [2]. 
 
In ISA100.11a, the system manager establishes a DL communication
relationship between a device and its neighbor by adding an entry to the
device's dlmo.Neighbor attribute (see Table 1). Each such entry specifies a
level of diagnostics to be collected, through the field
dlmo.Neighbor[].DiagLevel. For each neighbor, diagnostics may be collected
at a baseline level, or a detailed level including clock diagnostics [2].
This levels are described in Section 1.
Table 1. dlmo.Neighbor fields [2]

Field name
Field encoding

.
.

.
.
 
When the dlmo.Neighbor[].DiagLevel field is set for a particular neighbor,
the DL shall create corresponding entries in the read-only attribute
dlmo.NeighborDiag. NeighborDiag values are accumulated from the time that
the dlmo.NeighborDiag entry is created [2].
1.      dlmo.NeighborDiag:
dlmo.NeighborDiag is an indexed OctetString collection that contains
diagnostics for a set of neighbors. The attribute is read-only, with rows
created as needed by the DL [2].
NeighborDiag entries are instantiated by the system manager, by setting
dlmo.Neighbor[].DiagLevel bits to non-zero values. Iff (if and only if)
Bit0=1, then summary diagnostics shall be collected for the neighbor,
consolidated across all channels. Iff Bit1=1, then detailed clock
diagnostics shall be collected for the neighbor, consolidated across all
radio channels [2].
Table 2. dlmo.NeighborDiag fields [2]

Field name
Field encoding

* Index

Summary

ClockDetail

Field name
Field encoding

RSSI (level)
Type: Integer8

RSQI (level)
Type: Unsigned8

RxDPDU (count)
Type: ExtDlUint

TxSuccessful (count)
Type: ExtDlUint

TxFailed (count)
Type: ExtDlUint

TxCCA_Backoff (count)
Type: ExtDlUint

TxNACK (count)
Type: ExtDlUint

ClockSigma (level)
Type: Integer16

Field name
Field encoding

ClockCount (count)
Type: ExtDlUint

ClockTimeout (count)
Type: ExtDlUint

ClockOutliers (count)
Type: ExtDlUint
 
2.      dlmo.ChannelDiag:
dlmo.ChannelDiag is a read-only dynamic attribute that reports DPDU transmit
failure rates on each radio channel supported by the specification. This
enables the system manager to be aware of consistent connectivity problems
on a per-channel basis, as a diagnostic for spectrum management in a subnet
[2].
Two diagnostics are reported for each channel, each indicating a different
type of failure.  indicates the percentage of time that unicast DPDU
transmissions on channel N did not receive an ACK or a NACK.  indicates the
percentage of time that unicast DPDU transmissions on channel N were aborted
due to CCA. [2]
Table 5. dlmo.ChannelDiag fields

Field name
Field encoding

.

 
3.      Data link layer alerts
a.	DL_Connectivity alert
DL performance diagnostics are accumulated in the attributes
dlmo.NeighborDiag for per-neighbor diagnostics, and dlmo.ChannelDiag for
per-channel diagnostics. Normally the system manager configures the HRCO to
report these diagnostics periodically, and the DL automatically resets the
diagnostic counters whenever these attributes are so reported. Between such
reports, diagnostics may indicate a problem that needs to be reported to the
system manager immediately. The DL_Connectivity alert provides the mechanism
for the DL to report such issues, and the dlmo.AlertPolicy attribute enables
the system manager to set thresholds for such reporting [2].
The attribute dlmo.AlertPolicy enables/disables the DL_Connectivity alert
and provides thresholds to control whether alerts are reported.
dlmo.AlertPolicy is an OctetString containing fields as shown in Table 6
[2].
Table 6. dlmo.AlertPolicy fields

Field name
Field scalar type

NeiMinUnicast (Minimum number of unicast transactions needed for a neighbor
report.)
Type: ExtDlUint

NeiErrThresh (Report neighbor diagnostic if the percentage error rate
reaches this threshold )
Type: Unsigned8

ChanMinUnicast (Minimum number of unicast transactions on a channel needed
as a pre-condition for triggering an alert.)
Type: ExtDlUint

NoAckThresh (Report ChannelDiag if a NoAck value is greater than this
threshold)
Type: Unsigned8

CCABackoffThresh (Report ChannelDiag if a CCABackoff value is greater than
this threshold)
Type: Unsigned8
 
b.	NeighborDiscovery alert
The NeighborDiscovery alert provides a mechanism for the DL to report the
contents of the OctetString in dlmo.Candidates attribute (see Table 7).
The neighbors in the dlmo.Neighbor attribute are set by the system manager,
not by the device itself. The DL autonomously builds a list of candidate
neighbors in the dlmo.Candidates attribute. This list is then forwarded to
the system manager. The system manager considers the radio connectivity that
is reported in dlmo.Candidates, but may also consider other criteria such as
resource constraints, historical performance, or subnet topology [2].
Table 7. dlmo.Candidates OctetString fields

Field name
Field encoding

etc.

 
References
1.            IEC 62591: Industrial Communication Networks - Wireless
Communication Network and Communication Profiles - WirelessHART.
 
2.            IEC 62734: Industrial communication networks - Fieldbus
specifications - Wireless systems for industrial automation: process control
and related applications - ISA100.11a.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Xavier Vilajosana Guillen
Sent: Wednesday, September 11, 2013 8:54 PM
To: Thomas Watteyne
Cc: 6TSCH
Subject: Re: [6tsch] report flow contents
 
Hi Thomas, 
my 5 cents.
be used. Could we maybe define some "templates" or default configurations so
using the 6TiSCH can be done without configuration overhead? Then

On Wed, Sep 11, 2013 at 9:58 AM, Thomas Watteyne
<[email-masked]> wrote:
Pouria,
 
Wonderful list.
 
Your document clearly highlights that (1) the "report" flows both in
WirelessHART and ISA100.11a are strictly periodic and (1) they have a fixed
format. From what we have discussed so far, the solutions we are developing
is different in the following ways:
*	6TiSCH offers a mechanism allowing the PCE to configure what data it
want to receive, and configure the trigger for a node to generate from data.
*	6TiSCH offers a mechanism allowing the PCE to query the data, on top
of having the nodes push the information
*	In 6TiSCH, the format of the payload is not fixed. In particular, it
is possible to add application-specific fields, allowing for extensions.
*	In 6TiSCH, the transport (CoAP?) and formatting (CBOR?) are
IETF-friendly and integrate well in the IPv6 stack and associated mechanisms
Did I get that right?
 
A couple of questions:
*	the WirelessHART "alarms" correspond to a 6TiSCH "events". Yet, I
suppose that a "source route failed" and "graph route failed" are out of
scope of 6TiSCH, but rather part of RPL. I would expect those to the ICMPv6
messages. Thoughts?
*	About the per-channel report, I assume this is "per frequency",
right? Is a channel report generated for each neighbor?
*	When comparing your list to Xavi's
https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents:
*	we might want to add a "numNACK" counter to the neighbor information
*	we might want to keep timing statistics for all neighbors, not just
time source parents. That is, when I receive a packet from a neighbor which
is not my time source neighbor, I do not change my clock, but I still know
the timing error.
Thomas
 
On Wed, Sep 11, 2013 at 7:18 AM, <[email-masked]> wrote:
Dear All,
In the following, I listed the performance metrics reported to the
Network/System Manager in WirelessHART and ISA100.11a.
Some reports still need be added, for example the path failure alerts in
ISA100.11a.
Pouria
 
WirelessHART performance metrics
In WirelessHART[1] network the statistics and events are reported to the
Network Manager (act like PCE in 6TiSCH) through the following commands:
1.	Report "Device Health" 
This report is sent periodically toward the Network Manager. The report
summaries the communication statistics of a device.

Byte
Format
Description

0-1
Unsigned-16

2-3
Unsigned-16

4
Unsigned-8

5
Unsigned-8

6
Enum-8
Power Status

7
Unsigned-8
 
2.	Report "Neighbor Health List" 
This report is sent periodically toward the Network Manager. The report
includes the statistics of linked neighbors.

Byte
Format
Description

0
Unsigned-8
Neighbor table index

1
Unsigned-8

2
Unsigned-8

3-4
Unsigned-16
Nickname of neighbor

5
Bit-8
Neighbor Flags

6
Signed-8

7-8
Unsigned-16

9-10
Unsigned-16

11-12
Unsigned-16

13-.

3.	Report "Neighbor Signal Levels"
This report is sent periodically toward the Network Manager. The report
includes the statistics of discovered (but not linked) neighbors. These
neighbors might be discovered when a device has heard the neighbor
communication in the discovery links. A device that wish to join a network,
send a join request to the Network manager, including this report.

Byte
Format
Description

0
Unsigned-8
Neighbor table index

1
Unsigned-8

2
Unsigned-8

3-4
Unsigned-16
Nickname of neighbor

5
Signed-8
RSL of neighbor in dB

6-8

4.	Alarm "Path Down" 

Byte
Format
Description

0-1
Unsigned-16
 
5.	Alarm "Source Route Failed"
This alarm is sent upon detecting a source route failure.

Byte
Format
Description

0-1
Unsigned-16

2-5
Unsigned-32
NPDU that failed routing
 
6.	Alarm "Graph Route Failed"
This alarm is sent upon detecting a graph route failure.

Byte
Format
Description

0-1
Unsigned-16

ISA100.11a performance metric
In ISA100.11a[2], the L2 performance metrics are reported to the System
Manager (act like PCE in 6TiSCH) and can be classified into (1)
DL_Connectivity alert and (2) NeighborDiscovery alert.
1.	DL_Connectivity alert
The DL_connectivity alert can be classified into (a) Per-neighbor reports
and (b) Per-channel reports. 
*	Per-neighbor report
Per-neighbor reports are the  performance metrics about the neighbors
connection and are reported to the System Manager. These statistics are
accumulated in the "dlmo.NeighborDiag" attribute, for each neighbor. This
report is similar to "Neighbor Health List" report in WirelessHART. 
Each node in ISA100.11a might be asked to report the following statistics
about its neighbor:

Octets
Format
Description

1
Signed-8
RSSI (level)

1
Unsigned-8
RSQI (level)

1-2
ExtDLUint

1-2
ExtDLUint
neighbor 

1-2
ExtDLUint
or NACK

1-2
ExtDLUint

1-2
ExtDLUint

2
Signed-16
corrections
 
*	Per-channel report
In addition, in ISA100.11a, several performance metrics are reported based
on channel for all neighbors to the System Manager. These statistics are
accumulated in the "dlmo.ChannelDiag" attribute. This report is similar to
"Device Health" report in WirelessHART.

Byte
Format
Description

0-2
Unsigned-16

3
Integer-8

4
Integer-8

.

33
Integer-8

34
Integer-8
 
2.	NeighborDiscovery alert
In ISA100.11a, each node sends a report, including a list of candidate
(overheard) neighbors, to the System Manager to make a potential new routing
decisions. The "dlmo.Candidates" attributed is used to store those
information in each node in the L2. This report is similar to the "Neighbor
Signal Levels" report in WirelessHART.

Octets
Format
Description

1
Unsigned-8

0-2
ExtDlUint
address

0-1
Signed-8

0-1
Unsigned-8

.

0-2
ExtDlUint
address

0-1
Signed-8

0-1
Unsigned-8

References
1.       IEC 62591: Industrial Communication Networks - Wireless
Communication Network and Communication Profiles - WirelessHART.
 
2.       IEC 62734: Industrial communication networks - Fieldbus
specifications - Wireless systems for industrial automation: process control
and related applications - ISA100.11a.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thomas Watteyne
Sent: Saturday, September 07, 2013 7:43 PM
To: Xavi Vilajosana
Cc: Pascal Thubert (pthubert); [email-masked]
Subject: Re: [6tsch] report flow contents
 
Xavi,
Great, thanks!
Thomas
 
On Fri, Sep 6, 2013 at 5:01 PM, Xavier Vilajosana Guillen
<[email-masked]> wrote:
Hi, 
I created the scratchpad section in the wiki to keep ideas
https://bitbucket.org/6tsch/meetings/wiki/Home

 
On Fri, Sep 6, 2013 at 10:43 AM, Xavier Vilajosana Guillen
<[email-masked]> wrote:
Hi Pascal, it is a good idea!
I will collect that information and as Thomas put it at the wiki so we do
not lose it.

:-)
X
 
On Fri, Sep 6, 2013 at 8:51 AM, Pascal Thubert (pthubert)
<[email-masked]> wrote:
Hello Xavi:
 
At the call I mentioned we could use info on tracks and cells as well,
probably on demand from the PCE.
For instance, the PCE could observe energy levels over some cells for  a
while to make sure they are clean.
 
What do you think?
Pascal
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Xavier Vilajosana Guillen
Sent: vendredi 6 septembre 2013 01:17
To: Thomas Watteyne
Cc: [email-masked]
Subject: Re: [6tsch] report flow contents
 
agreed!
So the fields become:

For each known neighbor:
 -ID

 -For each Queue:
 
-Time source parent
    -ID

as regards to this:

 
would that work?
X
 
On Thu, Sep 5, 2013 at 4:03 PM, Thomas Watteyne <[email-masked]>
wrote:
Xavi,
 
Fantastic!
 
I believe PDR for each link might be too long to fit in a packet. While the
mote will most likely keep that information, we could move that to the query
flow, i.e. it is available to the PCE on-demand.

In queuing, it might be interesting to see the age of the different packets,
to be able to monitor latency.

 
Finally, do you envision a generic mechanism whereby the PCE can turn fields
on/off, or triggered independently?
 
Thomas

I agree that LQI should be there as well. I update here the list with Thomas
suggestions. 
 
For each known neighbor:
 -ID
 
Other fields

Hope this makes sense.
cheers!
Xavi

Xavi,
 
A few thoughts:
 
Thomas
 
On Thu, Sep 5, 2013 at 11:15 AM, Xavier Vilajosana Guillen
<[email-masked]> wrote:
Hello, I guess that flows are getting defined and I started to think on the
contents of the messages on that flows. Not sure if this is the right time
or I am going way far..

ME-6TOP - Query Flow
ME-6TOP - Action Flow
 
6TOP - ME - Report Flow
6TOP - ME - Event Flow

The Report Flow: has to deal with the information that a node knows and has
to be sent to the ME so the ME can compute the schedule among others. Here I
list  the information that we can know in a mote and can be used at the ME
to compute the schedule (complete please if I miss something)
 
For each known neighbor:
 -ID
 
Other fields

what do you think?
X

In this thread, we will continue the discussion about Confirmation message.
Here is some background information.
 
Context: e.g.
 
IMHO, different control flow may have different requirement for confirmation
message.
 
What do you think?
 
Thanks
Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 12 Sep 2013 17:48:49 -0700

Pouria,
Thanks again for the overview, which complements your first document nicely.

Alfredo,
Could you please elaborate what you mean by in-network processing? Are you
referring to a distributed way for the nodes to "consume" this data, some
fusion as the data trickles up the DAG, or something else?

Thomas

On Thu, Sep 12, 2013 at 12:34 AM, Alfredo Grieco
<[email-masked]>wrote:

> Hi All,****
> in-network processing ? ****
>
> ** **
>
> This would be very useful to distributed/decentralized scheduling
> techniques and should not cost that much.****
>
> ** **
>
> Any thoughts is welcome.****
>
> ** **
>
> Cheers****
>
> ** **
>
> Alfredo****
>
> ** **
>
> *Da:* [email-masked] [mailto:[email-masked]] *Per conto
> di [email-masked]
> *Inviato:* Wednesday, September 11, 2013 10:45 PM
> *A:* [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Oggetto:* Re: [6tsch] report flow contents****
>
> ** **
>
> Thomas,****
>
> I agree with you that "source route failed" and "graph route failed" are
> out of scope of 6TiSCH.****
>
> based on each radio channel supported by the specification (channel 11-26
> in 2.4GHz in IEEE 802.15.4), not channel offset. And a channel report
> generated for all neighbor.****
>
> 6TiSCH). For example in WirelessHART [1], by “Report Neighbor Health List”
> read in “Number of Neighbor entries read” field.. ****
>
> you mentioned might also be supported by ISA100.11a.****
>
> and dlmo.ChannelDiag (described in Section 2 later):****
>
>    1. The health reports concentrator object (HRCO), can be configured to
>    report any attribute in the DL *on a* *periodic basis*.
>    dlmo.NeighborDiag entries (shown in Table 2) and dlmo.ChannelDiag (shown in
>    Table 5) can be reported through that mechanism. Through the HRCO, the
>    system manager can configure the device to report NeighborDiag
>    periodically, such as every 30 minutes. Following each such report, on a
>    per-entry basis, NeighborDiag counts shall be reset to zero. Levels shall
>    use the current value as a starting point for the next period [2].****
>    2. Diagnostic information can be retrieved at any time by the system
>    (poll) NeighborDiag as a read-only attribute *on a per-entry basis*.
>    As in an HRCO report, counts shall be reset to zero when read [2].****
>    3. Diagnostic information can be reported by the DL on *an exception
>    basis*, through the DL_Connectivity alert (Described in section 3(a)).
>    The DL can additionally be configured, through the dlmo.AlertPolicy
>    attribute (shown in Table 6), to report NeighborDiag information when
>    diagnostic values exceed a threshold. Only the row triggering the alert is
>    reported. No values are reset [2]. ****
>
> ** **
>
> device’s dlmo.Neighbor attribute (see Table 1). Each such entry specifies a
> This levels are described in Section 1.****
>
> *Table **1. dlmo.Neighbor fields [2]*
>
> *Field name*
>
> *Field encoding*
>
> * Index (16-bit address of neighbor)****
>
> ExtDlUint (used as an index)****
>
> EUI64 (EUI-64 identifier of the neighbor)****
>
> Type: Unsigned64****
>
> …****
>
> …****
>
> *DiagLevel* (selection of neighbor diagnostics to collect)****
>
> Type: Unsigned2****
>
> Bit0 = 1 Collect link diagnostics****
>
> Bit1 = 1 Collect clock diagnostics****
>
> …****
>
> …****
>
> ** **
>
> the dlmo.NeighborDiag entry is created [2].****
>
> ***1.      ****dlmo.NeighborDiag:*
>
> created as needed by the DL [2].****
>
> radio channels [2].****
> *Table **2. dlmo.NeighborDiag fields [2]*
>
> Field name****
>
> Field encoding****
>
> * Index****
>
> Type: ExtDlUint (neighbor address, used as an index)****
>
> *Summary*
>
> Type: OctetString (see Table 3)****
>
> *ClockDetail*
>
> Type: OctetString (see Table 4)****
>
> ** **
>
> *Table **3. Diagnostic Summary OctetString fields [2]*
>
> Field name****
>
> Field encoding****
>
> RSSI (level)****
>
> Type: Integer8****
>
> RSQI (level)****
>
> Type: Unsigned8****
>
> RxDPDU (count)****
>
> Type: ExtDlUint****
>
> TxSuccessful (count)****
>
> Type: ExtDlUint****
>
> TxFailed (count)****
>
> Type: ExtDlUint****
>
> TxCCA_Backoff (count)****
>
> Type: ExtDlUint****
>
> TxNACK (count)****
>
> Type: ExtDlUint****
>
> ClockSigma (level)****
>
> Type: Integer16****
>
> ** **
>
> *Table **4. Diagnostic ClockDetail OctetString fields [2]*
>
> Field name****
>
> Field encoding****
>
> ClockBias (level, signed)****
>
> Type: Integer16****
>
> ClockCount (count)****
>
> Type: ExtDlUint****
>
> ClockTimeout (count)****
>
> Type: ExtDlUint****
>
> ClockOutliers (count)****
>
> Type: ExtDlUint****
>
> ** **
>
> **2.      ***dlmo.ChannelDiag*:****
>
> dlmo.ChannelDiag is a read-only dynamic attribute that reports DPDU
> transmit failure rates on each radio channel supported by the
> specification. This enables the system manager to be aware of consistent
> connectivity problems on a per-channel basis, as a diagnostic for spectrum
> management in a subnet [2].****
>
> type of failure. **** indicates the percentage of time that unicast DPDU
> transmissions on channel N did not receive an ACK or a NACK. ****indicates the percentage of time that unicast DPDU transmissions on channel
> N were aborted due to CCA. [2]****
>
> *Table **5. dlmo.ChannelDiag fields*
>
> Field name****
>
> Field encoding****
>
> Type:Unsigned16****
> Type: Integer8****
> Type: Integer8****
> Type: Integer8****
> Type: Integer8****
> ***3.      ****Data link layer alerts*
>
>    1. *DL_Connectivity alert*
>
> dlmo.NeighborDiag for *per-neighbor* diagnostics, and dlmo.ChannelDiag
> for *per-channel* diagnostics. Normally the system manager configures the
> HRCO to report these diagnostics periodically, and the DL automatically
> resets the diagnostic counters whenever these attributes are so reported.
> Between such reports, diagnostics may indicate a problem that needs to be
> reported to the system manager immediately. The DL_Connectivity alert
> provides the mechanism for the DL to report such issues, and the
> dlmo.AlertPolicy attribute enables the system manager to set thresholds for
> such reporting [2].****
>
> [2].****
> *Table **6. dlmo.AlertPolicy fields*
>
> Field name****
>
> Field scalar type****
>
> Descriptor (Enables or disabled the DL_Connectivity alert.)****
>
> Type Alert report descriptor****
>
> NeiMinUnicast (Minimum number of unicast transactions needed for a
> neighbor report.)****
>
> Type: ExtDlUint****
>
> reaches this threshold )****
>
> Type: Unsigned8****
>
> as a pre-condition for triggering an alert.)****
>
> Type: ExtDlUint****
>
> threshold)****
> Type: Unsigned8****
> this threshold)****
> Type: Unsigned8****
>    1. *NeighborDiscovery alert***
>
> contents of the OctetString in dlmo.Candidates attribute (see Table 7).***
> *
>
> The neighbors in the dlmo.Neighbor attribute are set by the system
> manager, not by the device itself. The DL autonomously builds a list of
> candidate neighbors in the dlmo.Candidates attribute. This list is then
> forwarded to the system manager. The system manager considers the radio
> connectivity that is reported in dlmo.Candidates, but may also consider
> other criteria such as resource constraints, historical performance, or
> subnet topology [2].****
>
> *Table **7. dlmo.Candidates OctetString fields*
>
> Field name****
>
> Field encoding****
>
> Type: Unsigned8****
> Neighbor1 (16-bit address of first candidate)****
>
> Type: ExtDlUint****
>
> RSSI1 (radio signal quality of first candidate)****
>
> Type: Integer8****
>
> RSQI1 (radio signal quality of first candidate)****
>
> Type: Unsigned8****
>
> etc…****
>
> ** **
>
> NeighborN (16-bit address of Nth candidate)****
>
> Type: ExtDlUint****
>
> RSSIN (radio signal quality of Nth candidate)****
>
> Type: Integer8****
>
> RSQIN (radio signal quality of Nth candidate)****
>
> Type: Unsigned8****
>
> ** **
>
> *References*
>
> *Sent:* Wednesday, September 11, 2013 8:54 PM
> *To:* Thomas Watteyne
> *Cc:* 6TSCH
> Hi Thomas, ****
> my 5 cents.****
> time source parent neighbors. I will add to the wiki :-)****
>
> their system. ****
> On Wed, Sep 11, 2013 at 9:58 AM, Thomas Watteyne <
> Pouria,****
> Wonderful list.****
> is different in the following ways:****
>
>    of having the nodes push the information****
> Did I get that right?****
>
> ** **
>
> A couple of questions:****
>
>    messages. Thoughts?****
>    right? Is a channel report generated for each neighbor?****
>    https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents:****
>
>
>    - we might want to add a "numNACK" counter to the neighbor information*
>       ***
>       know the timing error.****
>
> Thomas****
>
> ** **
>
> On Wed, Sep 11, 2013 at 7:18 AM, <[email-masked]> wrote:****
>
> Dear All,****
>
> *WirelessHART performance metrics*****
>
> *ISA100.11a performance metric*****
>
> and (b) Per-channel reports. ****
>
>    - *Per-neighbor report*****
>
>    - *Per-channel report*****
>
> accumulated in the “dlmo.ChannelDiag” attribute. This report is similar to
> “Device Health” report in WirelessHART.****
>
> Byte****
>
> Format****
>
> Description****
>
> 0-2****
>
> Unsigned-16****
>
> (Percentage of time transmissions on channel 0 did not receive an ACK)****
>
> 4****
>
> Integer-8****
>
> (Percentage of time transmissions on channel 0 aborted due to CCA)****
>
> …****
>
>  ****
>
>  ****
>
> 33****
>
> Integer-8****
>
> (Percentage of time transmissions on channel 15 did not receive an ACK)***
> *
>
> 34****
>
> Integer-8****
>
> (Percentage of time transmissions on channel 15 aborted due to CCA)****
>
>  ****
>
> address****
> address****
> * *****
> *References*****

---

From: Qin Wang <[email-masked]>
Date: Fri, 13 Sep 2013 21:47:39 +0800

Hi Thomas and All,

I think the per-frequency report (or called per-channel report in
ISA100.11a) is important, because PCE can use it to build black frequency
list and update channel hopping sequence. But, I'm not sure if it makes
implementation too complex or not.

Thought?

Qin

On Fri, Sep 13, 2013 at 8:48 AM, Thomas Watteyne <[email-masked]

> On Thu, Sep 12, 2013 at 12:34 AM, Alfredo Grieco <[email-masked]
> > wrote:
>
>> Hi All,****
>>
>> ** **
>>
>> Regarding to your first question, let me now explain more. I think both
>> of these standard provide a mechanisms to make it possible for
>> System/Network Manager to also read (pull) desired attributes (But not all
>> the feature in 6TiSCH). For example in WirelessHART [1], by “Report
>> Neighbor Health List” request, the network manager might mention the number
>> of neighbors to be read in “Number of Neighbor entries read” field.. ****
>>
>> I think, ISA100.11a provides more mechanisms for System manager to get
>> the desired attributes from the field devices. And the first two features
>> that you mentioned might also be supported by ISA100.11a.****
>>
>>    1. The health reports concentrator object (HRCO), can be configured
>>    to report any attribute in the DL *on a* *periodic basis*.
>>    basis*, through the DL_Connectivity alert (Described in section
>>    3(a)). The DL can additionally be configured, through the dlmo.AlertPolicy
>> When the dlmo.Neighbor[].DiagLevel field is set for a particular
>> neighbor, the DL shall create corresponding entries in the read-only
>> attribute dlmo.NeighborDiag. NeighborDiag values are accumulated from the
>> time that the dlmo.NeighborDiag entry is created [2].****
>>
>> Two diagnostics are reported for each channel, each indicating a
>> different type of failure. **** indicates the percentage of time that
>> unicast DPDU transmissions on channel N did not receive an ACK or a NACK.
>> **** indicates the percentage of time that unicast DPDU transmissions on
>> channel N were aborted due to CCA. [2]****
>>
>> for *per-channel* diagnostics. Normally the system manager configures
>> the HRCO to report these diagnostics periodically, and the DL automatically
>> ChanMinUnicast (Minimum number of unicast transactions on a channel
>> needed as a pre-condition for triggering an alert.)****
>>
>> Type: ExtDlUint****
>>
>> CCABackoffThresh (Report ChannelDiag if a CCABackoff value is greater
>> than this threshold)****
>>
>> Type: Unsigned8****
>>
>> ** **
>>
>> contents of the OctetString in dlmo.Candidates attribute (see Table 7).**
>> **
>>
>>    - 6TiSCH offers a mechanism allowing the PCE to configure what data
>>    it want to receive, and configure the trigger for a node to generate from
>>    data.****
>>    - 6TiSCH offers a mechanism allowing the PCE to query the data, on
>>    top of having the nodes push the information****
>>    - In 6TiSCH, the format of the payload is not fixed. In particular,
>>    it is possible to add application-specific fields, allowing for extensions.
>>    ****
>> (Percentage of time transmissions on channel 15 did not receive an ACK)**
>> **
>>
>> 34****
>>
>> Integer-8****
>>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 13 Sep 2013 11:23:02 -0300

Hello Qin,
              I think that a per-frequency report will help the PCE
to decide which frequency to use, and maybe temporarily
black-list them. For example, a dynamic scheme may include
sampling the blacklisted frequencies every X minutes to re-enable
them once the interference has disappeared.
             This will require the node to refresh the RSSI
and LQI values in a opportunistic way (every time the a cell
uses that frequency) to save energy.

Any thoughts?

                            Diego

2013/9/13 Qin Wang <[email-masked]>

> On Fri, Sep 13, 2013 at 8:48 AM, Thomas Watteyne <
>> Could you please elaborate what you mean by in-network processing? Are
>> you referring to a distributed way for the nodes to "consume" this data,
>> some fusion as the data trickles up the DAG, or something else?
>>
>> Thomas
>>
>>
>> On Thu, Sep 12, 2013 at 12:34 AM, Alfredo Grieco <
>> [email-masked]> wrote:
>>
>>> Hi All,****
>>>
>>> ** **
>>>
>>> **** indicates the percentage of time that unicast DPDU transmissions
>>> on channel N were aborted due to CCA. [2]****
>>>
>>> **** (Percentage of time transmissions on channel 0 aborted due to CCA)*
>>> ***
>>>
>>> Type: Integer8****
>>>
>>> …****
>>>
>>> ** **
>>>
>>> **** (Percentage of time transmissions on channel 15 aborted due to CCA)
>>> ****
>>>
>>> Type: Integer8****
>>>
>>> ** **
>>>
>>> The attribute dlmo.AlertPolicy enables/disables the DL_Connectivity
>>> alert and provides thresholds to control whether alerts are reported.
>>> The NeighborDiscovery alert provides a mechanism for the DL to report
>>> the contents of the OctetString in dlmo.Candidates attribute (see Table 7).
>>> ****
>>>
>>> I agree on adding NACK information and timing differences with other
>>> than time source parent neighbors. I will add to the wiki :-)****
>>>
>>>    - we might want to add a "numNACK" counter to the neighbor
>>>       information****
>>> Each node in ISA100.11a might be asked to report the following
>>> statistics about its neighbor:****
>>>
>>>  ****
>>>
>>> Octets****
>>>
>>> Format****
>>>
>>> Description****
>>>
>>> 1****
>>>
>>> Signed-8****
>>>
>>> RSSI (level)****
>>>
>>> 1****
>>>
>>> Unsigned-8****
>>>
>>> RSQI (level)****
>>>
>>> 1-2****
>>>
>>> ExtDLUint****
>>>
>>> (Percentage of time transmissions on channel 15 did not receive an ACK)*
>>> ***
>>>
>>> 34****
>>>
>>> Integer-8****
>>>

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 13 Sep 2013 07:46:15 -0700

Qin, Diego,

My 2 cents. I agree with you that it would be nice for the PCE to be able
to get some per-channel information. Although adaptive channel hopping
(i.e. selectively blacklisting frequencies for a specific bundle) is
appealing in principle, it's unclear (at least to me) whether the gains
clearly outweigh the overhead (complexity, signalign traffic) one has to
pay to coordinate this [1-5].

My opinion is that we should enable both metrics averages over all
channels, and per-channel metrics. In some configurations, one can imagine
gathering the former by default, and querying for the latter on specific
occasions. Having the option of gathering per-channel information does
enable us to be future-proof against future adaptive channel hopping
algorithm.

For sure, this makes for a great question: how do a pair of motes and the
PCE have to communicate to enable adaptive channel hopping on that link?
The answer to that might directly impact the application payload formats we
have are talking about. Is this something you be interested in looking
further into?

Thomas

[1] A Decentralized Scheduling Algorithm for Time Synchronized Channel
Hopping. Andrew Tinka, Thomas Watteyne, Kris Pister, Alexandre M. Bayen.
ICST Transactions on Mobile Communications and Applications, 11(7-9).
European Union Digital Library link. doi:10.4108/icst.trans.mca.2011.e5.
September 2011.
[2] A Decentralized Scheduling Algorithm for Time Synchronized Channel
Hopping. Andrew Tinka, Thomas Watteyne, Kris Pister. International
Conference on Ad Hoc Networks (ADHOCNETS), Victoria, BC, Canada, 18-20
August 2010.
[3] Mitigating Multipath Fading Through Channel Hopping in Wireless Sensor
Networks. Thomas Watteyne, Steven Lanzisera, Ankur Mehta, Kris Pister. IEEE
International Conference on Communications (ICC), Cape Town, South Africa,
23-27 May, 2010.
[4] Feasibility Analysis of Controller Design for Adaptive Channel Hopping.
Branko Kerkez, Thomas Watteyne, Mario Magliocco, Steven Glaser, Kris
Pister. First International Workshop on Performance Methodologies and Tools
for Wireless Sensor Networks (WSNPerf), Pisa, Italy, 23 October 2009.
[5] Reliability Through Frequency Diversity: Why Channel Hopping Makes
Sense. Thomas Watteyne, Ankur Mehta, Kris Pister. Sixth ACM International
Symposium on Performance Evaluation of Wireless Ad Hoc, Sensor, and
Ubiquitous Networks (PE-WASUN), Tenerife, Canary Islands, Spain, 26-30
October 2009.

---

From: Qin Wang <[email-masked]>
Date: Fri, 13 Sep 2013 22:55:02 +0800

Hi Diego,

Comparing the per-frequency report with the RSSI/LQI in the per-neighbor
report defined on
https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents, I think the
first one refers to the radio condition in a area, not specific to a
neighbor; and the second one likely focuses on the average  RSSI/LQI of all
frequencies applied in a cell/bundle, not specific to a radio frequency.
Make sense?

Thanks
Qin

On Fri, Sep 13, 2013 at 10:23 PM, Prof. Diego Dujovne <
[email-masked]> wrote:

>>>> *Da:* [email-masked] [mailto:[email-masked]] *Per
>>>> conto di [email-masked]
>>>> I agree with you that "source route failed" and "graph route failed"
>>>> are out of scope of 6TiSCH.****
>>>>
>>>> Regarding to you question about the per-channel report, I think they
>>>> are based on each radio channel supported by the specification (channel
>>>> 11-26 in 2.4GHz in IEEE 802.15.4), not channel offset. And a channel report
>>>>    2. Diagnostic information can be retrieved at any time by the
>>>>    system manager, by reading the applicable attributes. The system manager
>>>>    can read (poll) NeighborDiag as a read-only attribute *on a
>>>>    per-entry basis*. As in an HRCO report, counts shall be reset to
>>>>    zero when read [2].****
>>>>    3. Diagnostic information can be reported by the DL on *an
>>>>    exception basis*, through the DL_Connectivity alert (Described in
>>>>    section 3(a)). The DL can additionally be configured, through the
>>>>    dlmo.AlertPolicy attribute (shown in Table 6), to report NeighborDiag
>>>>    information when diagnostic values exceed a threshold. Only the row
>>>>    triggering the alert is reported. No values are reset [2]. ****
>>>>
>>>> ** **
>>>>
>>>> **** (Percentage of time transmissions on channel 0 aborted due to CCA)
>>>> ****
>>>>
>>>> Type: Integer8****
>>>>
>>>> …****
>>>>
>>>> ** **
>>>>
>>>> **** (Percentage of time transmissions on channel 15 did not receive
>>>> an ACK)****
>>>>
>>>> Type: Integer8****
>>>>
>>>> **** (Percentage of time transmissions on channel 15 aborted due to
>>>> CCA)****
>>>>
>>>> Type: Integer8****
>>>>
>>>> ** **
>>>>
>>>> Some reports still need be added, for example the path failure alerts
>>>> in ISA100.11a.****
>>>>
>>>> Pouria****
>>>>
>>>>  ****
>>>>
>>>> In WirelessHART[1] network the statistics and events are reported to
>>>> the Network Manager (act like PCE in 6TiSCH) through the following commands:
>>>> ****
>>>>
>>>> For instance, the PCE could observe energy levels over some cells for
>>>> a while to make sure they are clean.****
>>>>
>>>>  ****
>>>>
>>>> What do you think?****
>>>>
>>>> Pascal****
>>>>
>>>>  ****
>>>>
>>>> ignore silently fields it does not understand.****
>>>>
>>>>  ****
>>>>
>>>> Thomas****
>>>>
>>>>  ****
>>>>
>>>> On Fri, Aug 30, 2013 at 10:45 AM, Qin Wang <[email-masked]>
>>>> wrote:****
>>>>
>>>> Hi all,****
>>>>
>>>>  ****
>>>>
>>>> message packet corresponding to a specific query.****
>>>>

---

From: Qin Wang <[email-masked]>
Date: Fri, 13 Sep 2013 23:04:14 +0800

Thomas,

I agree with you that it is not clear what is the advantage and
disadvantage of adaptive channel hopping in reality.

In mind, based on the per-frequency report, PCE can do two things: (1)
update channel hopping sequence is a frequency is really bad network wide;
(2) avoid use some bad channel when it runs cell allocation algorithm.  The
two things happen in PCE, so, will not make negative impact on the network.
Thought?

Thanks

Qin

On Fri, Sep 13, 2013 at 10:46 PM, Thomas Watteyne <
[email-masked]> wrote:

> [4] Feasibility Analysis of Controller Design for Adaptive Channel
> Hopping. Branko Kerkez, Thomas Watteyne, Mario Magliocco, Steven Glaser,
> Kris Pister. First International Workshop on Performance Methodologies and
> Tools for Wireless Sensor Networks (WSNPerf), Pisa, Italy, 23 October 2009.

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 13 Sep 2013 12:28:34 -0300

Qin,
      I think frequency blacklisting on a node-pair basis (either
centralized or distributed) would
break the schedule matrix structure, which overrides narrowband
interference by channel hopping.
If frequencies are blacklisted on all slots, that would waste
resources. Narrowband interference
can harm the link locally, but the same frequency may be
interference-free in other parts of
the net.
      The dynamic allocation I propose was only an example. If you
have 16 frequencies
and 2 of them have interference, and the channel offset is sequential,
you may loose 2 packets
every 16. Am I right on this?

Thoughts?

                                                      Diego

2013/9/13 Qin Wang <[email-masked]>:
> Thomas,
>
> I agree with you that it is not clear what is the advantage and disadvantage
> of adaptive channel hopping in reality.
>
> On Fri, Sep 13, 2013 at 10:46 PM, Thomas Watteyne
>> to get some per-channel information. Although adaptive channel hopping (i.e.
>> selectively blacklisting frequencies for a specific bundle) is appealing in
>> principle, it's unclear (at least to me) whether the gains clearly outweigh
>> the overhead (complexity, signalign traffic) one has to pay to coordinate
>> this [1-5].
>>
>> PCE have to communicate to enable adaptive channel hopping on that link? The
>> answer to that might directly impact the application payload formats we have
>> are talking about. Is this something you be interested in looking further
>> into?
>>
>> Thomas
>>
>> On Fri, Sep 13, 2013 at 7:23 AM, Prof. Diego Dujovne
>> <[email-masked]> wrote:
>>>
>>> Hello Qin,

---

From: <[email-masked]>
Date: Fri, 13 Sep 2013 16:45:36 +0000

Dear All,
Regarding to the Xavi's report list, I found "per-cell" reports for each node (in addition to potential "per-frequency" and "per-neighbor" reports) in the list. I have the following concerns, 
(1) In the centralized management approach, what is the gain of reporting the statistics "per-cell"? Per-cell information will be used to evaluate the potential internal-interference caused by other neighboring communication. Am I right? Shouldn't the PCE, take care of allocation of cells (either dedicated or shared cells)? I mean, shouldn't the PCE take care of not allocating (re-using) the dedicated cell to two different pairs? Shouldn't the PCE take care of allocating the shared cell to the limited number of transmitters? 
(2) For sure, in the "per-frequency" and "per-neighbor" reports, each node has a limited number of frequencies (i.e. 11-26 in 2.4GHz) and a maximum number of linked-neighbors to report. However, in reporting "per-cell", what is the maximum number of cells defined for a node? (We might also consider the dense traffic scenarios).
Am I missing anything?
Best Wishes,
Pouria  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: Friday, September 13, 2013 5:29 PM
To: Qin Wang
Cc: Thomas Watteyne; 6TSCH
Subject: Re: [6tsch] report flow contents

Qin,
      I think frequency blacklisting on a node-pair basis (either centralized or distributed) would break the schedule matrix structure, which overrides narrowband interference by channel hopping.
If frequencies are blacklisted on all slots, that would waste resources. Narrowband interference can harm the link locally, but the same frequency may be interference-free in other parts of the net.
      The dynamic allocation I propose was only an example. If you have 16 frequencies and 2 of them have interference, and the channel offset is sequential, you may loose 2 packets every 16. Am I right on this?

Thoughts?

                                                      Diego

2013/9/13 Qin Wang <[email-masked]>:
> (2) avoid use some bad channel when it runs cell allocation algorithm.  
> The two things happen in PCE, so, will not make negative impact on the network.
> Thought?
>
> Thanks
>
> Qin
>
>
>
>
>> My 2 cents. I agree with you that it would be nice for the PCE to be 
>> able to get some per-channel information. Although adaptive channel hopping (i.e.
>> selectively blacklisting frequencies for a specific bundle) is 
>> appealing in principle, it's unclear (at least to me) whether the 
>> gains clearly outweigh the overhead (complexity, signalign traffic) 
>> one has to pay to coordinate this [1-5].
>>
>> channels, and per-channel metrics. In some configurations, one can 
>> imagine gathering the former by default, and querying for the latter 
>> on specific occasions. Having the option of gathering per-channel 
>> information does enable us to be future-proof against future adaptive 
>> channel hopping algorithm.
>>
>> For sure, this makes for a great question: how do a pair of motes and 
>> the PCE have to communicate to enable adaptive channel hopping on 
>> that link? The answer to that might directly impact the application 
>> payload formats we have are talking about. Is this something you be 
>> interested in looking further into?
>>
>> Thomas
>>
>> [1] A Decentralized Scheduling Algorithm for Time Synchronized 
>> Channel Hopping. Andrew Tinka, Thomas Watteyne, Kris Pister, Alexandre M. Bayen.
>> [2] A Decentralized Scheduling Algorithm for Time Synchronized 
>> Channel Hopping. Andrew Tinka, Thomas Watteyne, Kris Pister. 
>> International Conference on Ad Hoc Networks (ADHOCNETS), Victoria, 
>> BC, Canada, 18-20 August 2010.
>> [3] Mitigating Multipath Fading Through Channel Hopping in Wireless 
>> Sensor Networks. Thomas Watteyne, Steven Lanzisera, Ankur Mehta, Kris 
>> Pister. IEEE International Conference on Communications (ICC), Cape 
>> Town, South Africa,
>> 23-27 May, 2010.
>> Hopping. Branko Kerkez, Thomas Watteyne, Mario Magliocco, Steven 
>> Glaser, Kris Pister. First International Workshop on Performance 
>> Methodologies and Tools for Wireless Sensor Networks (WSNPerf), Pisa, Italy, 23 October 2009.
>> [5] Reliability Through Frequency Diversity: Why Channel Hopping 
>> Makes Sense. Thomas Watteyne, Ankur Mehta, Kris Pister. Sixth ACM 
>> International Symposium on Performance Evaluation of Wireless Ad Hoc, 
>> Sensor, and Ubiquitous Networks (PE-WASUN), Tenerife, Canary Islands, 
>> Spain, 26-30 October 2009.
>>
>>> to decide which frequency to use, and maybe temporarily black-list 
>>> them. For example, a dynamic scheme may include sampling the 
>>> blacklisted frequencies every X minutes to re-enable them once the 
>>> interference has disappeared.
>>>              This will require the node to refresh the RSSI and LQI 
>>> values in a opportunistic way (every time the a cell uses that 
>>> frequency) to save energy.
>>>
>>> Any thoughts?
>>>
>>>                             Diego
>>
>>

--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones Facultad de Ingeniería UDP www.ingenieria.udp.cl
(56 2) 676 8125
_______________________________________________
6tsch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tsch

---

From: Qin Wang <[email-masked]>
Date: Sat, 14 Sep 2013 02:11:11 +0800

Hi Diego,

I understand, theoretically, dynamic allocation may have some advantages in
terms of increasing reliability. But, in the channel hopping network, it is
challenge for a node to catch up the channel hopping sequence change in its
neighbors. Thus, I think, if updating channel hopping sequence, it could be
better to do it in network wide. What do you think?

Thanks
Qin

On Fri, Sep 13, 2013 at 11:28 PM, Prof. Diego Dujovne <
[email-masked]> wrote:

>  The
> able
> (i.e.
> appealing in
> imagine
> the
> Sensor

---

From: Qin Wang <[email-masked]>
Date: Sat, 14 Sep 2013 02:22:27 +0800

Hi Pouria,

In the centralized case, I believe PCE will take care everything you
mentioned. That means internal-interference caused by other neighboring
communication should not be the contributor to low link quality of a cell.
Thus, I think PCE will use per-cell report to adjust over-provision of
cells. For example, when PCE found a bundle of cells can not achieve
required BW, PCE may assign more cells.

Make sense?
Qin

On Sat, Sep 14, 2013 at 12:45 AM, <[email-masked]> wrote:

> Dear All,
> Regarding to the Xavi's report list, I found "per-cell" reports for each
> node (in addition to potential "per-frequency" and "per-neighbor" reports)
> in the list. I have the following concerns,
> (1) In the centralized management approach, what is the gain of reporting
> the statistics "per-cell"? Per-cell information will be used to evaluate
> the potential internal-interference caused by other neighboring
> communication. Am I right? Shouldn't the PCE, take care of allocation of
> cells (either dedicated or shared cells)? I mean, shouldn't the PCE take
> care of not allocating (re-using) the dedicated cell to two different
> pairs? Shouldn't the PCE take care of allocating the shared cell to the
> limited number of transmitters?
> (2) For sure, in the "per-frequency" and "per-neighbor" reports, each node
> has a limited number of frequencies (i.e. 11-26 in 2.4GHz) and a maximum
> number of linked-neighbors to report. However, in reporting "per-cell",
> what is the maximum number of cells defined for a node? (We might also
> consider the dense traffic scenarios).
> Am I missing anything?
> Best Wishes,
> Pouria
>
> Prof. Diego Dujovne
> centralized or distributed) would break the schedule matrix structure,
> which overrides narrowband interference by channel hopping.
> If frequencies are blacklisted on all slots, that would waste resources.
> Narrowband interference can harm the link locally, but the same frequency
> may be interference-free in other parts of the net.
>       The dynamic allocation I propose was only an example. If you have 16
> frequencies and 2 of them have interference, and the channel offset is
> sequential, you may loose 2 packets every 16. Am I right on this?
>
> Thoughts?
>
>                                                       Diego
>
>
> Facultad de Ingeniería UDP www.ingenieria.udp.cl
> (56 2) 676 8125

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 13 Sep 2013 16:06:49 -0300

Hi Qin,
          On the centralized case, changing the channel hopping
sequence (and thus blacklisting the channels with interference)
on the whole network, and not in a peer basis is not efficient in
terms of channel usage. Let me explain this with an
example:

Let's say there is are 4 nodes: A, B, C and D. A and B are interfered
only on channel 4 by an external source, while C and D listen
interference only on channel 8. If I disable channel 4 and 8 by
blacklisting both channels from the hopping sequence,
A and B won't be able to use channel 8 and C and D won't be able to
use channel 4, both interference free between them.

On the distributed case, if two nodes are already connected and if
both detect a interfered channel they will (someway) agree
to blacklist that channel from the hopping sequence. But we have not
arrived to this case yet on 6TiSCH.

On the other side, if we blacklist by changing the hopping sequence, a
node talking to different neighbours will have different
channel hopping sequences. And this increases complexity too.

I don't have an answer (just questions) on how to reduce the
probability of using an interfered channel, but it seems that
the current tsch scheme does not allow a simple way to blacklist
channels unless it is done network-wide. To sum up,
I'm worrying about reducing channel diversity.

Thoughts?

                                                         Diego

2013/9/13 Qin Wang <[email-masked]>:
> On Fri, Sep 13, 2013 at 11:28 PM, Prof. Diego Dujovne
>> >> Glaser,

---

From: <[email-masked]>
Date: Mon, 16 Sep 2013 00:56:18 +0000

Hi Diego,

ISA100.11a considers the adaptive channel hopping on a link-by-link basis, in addition to traditional blacklisting on the whole network. This mechanism is described as following:

"Additionally, a device may autonomously treat transmit links on problematic channels as idle, thus reducing unnecessary interference and wasted energy on channels with a history of poor connectivity. A device skipping links in this manner should periodically test the links to verify that they remain problematic. Such selective channel utilization can be disabled by the system manager on a link-by-link basis, through the attribute dlmo.Link[].Type.SelectiveAllowed. [1]"

In this scheme, the sender/receiver consider the poor channel as idle. The sender and receiver (on the poor edge) will still follow the defined hopping pattern and they will not conflict with the rest of the network. 
Potential Drawbacks: 1/16 of the resources might be wasted on that edge, but the poor channel of that edge will be skipped, locally. 
Important Strength: The overhead of this scheme is low.

Best wishes,
puoria

1. IEC 62734: Industrial communication networks - Fieldbus specifications - Wireless systems for industrial automation: process control and related applications - ISA100.11a.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: Friday, September 13, 2013 9:07 PM
To: Qin Wang
Cc: Thomas Watteyne; 6TSCH
Subject: Re: [6tsch] report flow contents

Hi Qin,
          On the centralized case, changing the channel hopping sequence (and thus blacklisting the channels with interference) on the whole network, and not in a peer basis is not efficient in terms of channel usage. Let me explain this with an
example:

Let's say there is are 4 nodes: A, B, C and D. A and B are interfered only on channel 4 by an external source, while C and D listen interference only on channel 8. If I disable channel 4 and 8 by blacklisting both channels from the hopping sequence, A and B won't be able to use channel 8 and C and D won't be able to use channel 4, both interference free between them.

On the distributed case, if two nodes are already connected and if both detect a interfered channel they will (someway) agree to blacklist that channel from the hopping sequence. But we have not arrived to this case yet on 6TiSCH.

On the other side, if we blacklist by changing the hopping sequence, a node talking to different neighbours will have different channel hopping sequences. And this increases complexity too.

I don't have an answer (just questions) on how to reduce the probability of using an interfered channel, but it seems that the current tsch scheme does not allow a simple way to blacklist channels unless it is done network-wide. To sum up, I'm worrying about reducing channel diversity.

Thoughts?

                                                         Diego

2013/9/13 Qin Wang <[email-masked]>:
> Hi Diego,
>
> I understand, theoretically, dynamic allocation may have some 
> advantages in terms of increasing reliability. But, in the channel 
> hopping network, it is challenge for a node to catch up the channel 
> hopping sequence change in its neighbors. Thus, I think, if updating 
> channel hopping sequence, it could be better to do it in network wide. What do you think?
>
> Thanks
> Qin
>
>
>> centralized or distributed) would break the schedule matrix 
>> structure, which overrides narrowband interference by channel 
>> hopping.
>> resources. Narrowband interference can harm the link locally, but the 
>> same frequency may be interference-free in other parts of the net.
>> have 16 frequencies and 2 of them have interference, and the channel 
>> offset is sequential, you may loose 2 packets every 16. Am I right on 
>> this?
>>
>> Thoughts?
>>
>>                                                       Diego
>>
>>
>> > In mind, based on the per-frequency report, PCE can do two things: 
>> > (1) update channel hopping sequence is a frequency is really bad 
>> > network wide;
>> >> My 2 cents. I agree with you that it would be nice for the PCE to 
>> >> be able to get some per-channel information. Although adaptive 
>> >> channel hopping (i.e.
>> >> gains clearly outweigh the overhead (complexity, signalign 
>> >> traffic) one has to pay to coordinate this [1-5].
>> >>
>> >> imagine gathering the former by default, and querying for the 
>> >> latter on specific occasions. Having the option of gathering 
>> >> per-channel information does enable us to be future-proof against 
>> >> future adaptive channel hopping algorithm.
>> >>
>> >> For sure, this makes for a great question: how do a pair of motes 
>> >> and the PCE have to communicate to enable adaptive channel hopping 
>> >> on that link? The answer to that might directly impact the 
>> >> application payload formats we have are talking about. Is this 
>> >> something you be interested in looking further into?
>> >>
>> >> Thomas
>> >>
>> >> [3] Mitigating Multipath Fading Through Channel Hopping in 
>> >> Wireless Sensor Networks. Thomas Watteyne, Steven Lanzisera, Ankur 
>> >> Mehta, Kris Pister.
>> >> IEEE
>> >> International Symposium on Performance Evaluation of Wireless Ad 
>> >> Hoc, Sensor, and Ubiquitous Networks (PE-WASUN), Tenerife, Canary 
>> >> Islands, Spain, 26-30 October 2009.
>> >>
>> >>>               I think that a per-frequency report will help the 
>> >>> PCE to decide which frequency to use, and maybe temporarily 
>> >>>              This will require the node to refresh the RSSI and 
>> >>> LQI values in a opportunistic way (every time the a cell uses 
>> >>> that frequency) to save energy.
>> >>>
>> >>> Any thoughts?
>> >>>
>> >>>                             Diego
>> >>
>> >>

---

From: Qin Wang <[email-masked]>
Date: Mon, 16 Sep 2013 22:34:47 +0800

Hi Pouria and Diego,

I think the "link-by-link" adaptive channel hopping mechanism of ISA100.11a
AND cell over-provision mechanism of 6top can be used together. Make sense?

Thanks
Qin

On Mon, Sep 16, 2013 at 8:56 AM, <[email-masked]> wrote:

> Hi Diego,
>
> ISA100.11a considers the adaptive channel hopping on a link-by-link basis,
> in addition to traditional blacklisting on the whole network. This
> mechanism is described as following:
>
> "Additionally, a device may autonomously treat transmit links on
> problematic channels as idle, thus reducing unnecessary interference and
> wasted energy on channels with a history of poor connectivity. A device
> skipping links in this manner should periodically test the links to verify
> that they remain problematic. Such selective channel utilization can be
> disabled by the system manager on a link-by-link basis, through the
> attribute dlmo.Link[].Type.SelectiveAllowed. [1]"
>
> In this scheme, the sender/receiver consider the poor channel as idle. The
> sender and receiver (on the poor edge) will still follow the defined
> hopping pattern and they will not conflict with the rest of the network.
> Potential Drawbacks: 1/16 of the resources might be wasted on that edge,
> but the poor channel of that edge will be skipped, locally.
> 1. IEC 62734: Industrial communication networks - Fieldbus specifications
> - Wireless systems for industrial automation: process control and related
> applications - ISA100.11a.
>
>           On the centralized case, changing the channel hopping sequence
> (and thus blacklisting the channels with interference) on the whole
> network, and not in a peer basis is not efficient in terms of channel
> usage. Let me explain this with an
> example:
>
> Let's say there is are 4 nodes: A, B, C and D. A and B are interfered only
> on channel 4 by an external source, while C and D listen interference only
> on channel 8. If I disable channel 4 and 8 by blacklisting both channels
> from the hopping sequence, A and B won't be able to use channel 8 and C and
> D won't be able to use channel 4, both interference free between them.
>
> On the distributed case, if two nodes are already connected and if both
> detect a interfered channel they will (someway) agree to blacklist that
> channel from the hopping sequence. But we have not arrived to this case yet
> on 6TiSCH.
>
> node talking to different neighbours will have different channel hopping
> sequences. And this increases complexity too.
>
> I don't have an answer (just questions) on how to reduce the probability
> of using an interfered channel, but it seems that the current tsch scheme
> does not allow a simple way to blacklist channels unless it is done
> network-wide. To sum up, I'm worrying about reducing channel diversity.
>
> Thoughts?
>
>                                                          Diego
>
>
>
>
>
>
> >> >> Channel Hopping. Andrew Tinka, Thomas Watteyne, Kris Pister,
> Alexandre M.
> >> >> Bayen.

---

From: <[email-masked]>
Date: Mon, 16 Sep 2013 16:35:27 +0000

Hi Qin,

"Link-by-link" adaptive channel hopping in ISA is used by a node to select the best frequencies for its further communication with its particular neighbor.
And, cell over-provision (i.e. the combination of "channel offset" and "slot" info used for communication with a particular neighbor), might be used for evaluating the internal interference and BW requirements between two neighbors. Am I right?

Best wishes,
Pouria Zand

On Sep 16, 2013, at 4:34 PM, "Qin Wang" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Pouria and Diego,

I think the "link-by-link" adaptive channel hopping mechanism of ISA100.11a AND cell over-provision mechanism of 6top can be used together. Make sense?

Thanks
Qin

On Mon, Sep 16, 2013 at 8:56 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Diego,

Best wishes,
puoria

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Prof. Diego Dujovne
Sent: Friday, September 13, 2013 9:07 PM
To: Qin Wang
Cc: Thomas Watteyne; 6TSCH
Subject: Re: [6tsch] report flow contents

Hi Qin,

Thoughts?

                                                         Diego

2013/9/13 Qin Wang <[email-masked]<mailto:[email-masked]>>:
> <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Qin,
>> 2013/9/13 Qin Wang <[email-masked]<mailto:[email-masked]>>:
>> > Thomas,
>> >
>> > <[email-masked]<mailto:[email-masked]>> wrote:
>> >>
>> >> Qin, Diego,
>> >>
>> >> <[email-masked]<mailto:[email-masked]>> wrote:
>> >>>
>> >>> Hello Qin,
>> Facultad de Ingeniería UDP www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
>> (56 2) 676 8125
>
>

www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>