Subject: Re: [6tsch] (no subject)

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

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

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 5 Sep 2013 15:33:24 -0400

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

                      Diego Dujovne

2013/9/5 Xavier Vilajosana Guillen <[email-masked]>:
> 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
> 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