Re: [6tsch] (no subject)

["Prof. Diego Dujovne" <[e-mail]>]

Xavi,
       I would add the LQI measurement too for each neighbor (AVG+Latest).
Regards,

                      Diego Dujovne

2013/9/5 Xavier Vilajosana Guillen <[e-mail]>du>:
> 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
>



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