Re: [6tsch] report flow contents

[Xavier Vilajosana Guillen <[e-mail]>]

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 <[e-mail]
> 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 <
> [e-mail]> 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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>
>>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>>
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>