Re: [6tsch] Mobility in 6TSCH

+1 for relocation,

"node relocation"

IMHO is the most suitable candidate.

:-)
X

On Sat, Jul 27, 2013 at 11:41 AM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

>  Dear all;****
>
> ** **
>
> I love the term “relocation”. ****
>
> We probably want a relocation that is transparent to the upper layers.****
>
> The topology can also be qualified as relatively stable.****
>
> ** **
>
> What do others think?****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On Behalf
> Of *Alfredo Grieco
> *Sent:* samedi 27 juillet 2013 10:04
> *To:* Thomas Watteyne
> *Cc:* 6tsch@ietf.org
> *Subject:* Re: [6tsch] Mobility in 6TSCH****
>
> ** **
>
> Almost static topologies ?****
>
> ** **
>
> Alfredo
>
> On Saturday, July 27, 2013, Thomas Watteyne wrote:****
>
> Pascal,****
>
> ** **
>
> I understand you are looking for the right term.****
>
> ** **
>
> Terms I can think of:****
>
> - roaming****
>
> - node relocation****
>
> - occasional mobility****
>
> - intermittent relocation****
>
> ** **
>
> Thomas****
>
> ** **
>
> On Fri, Jul 26, 2013 at 7:50 PM, Qin Wang <qinwang@berkeley.edu> wrote:***
> *
>
> Hi Pascal and All,****
>
> ** **
>
> How about "dynamic adjustment". Because,****
>
> ** **
>
> In steady network (fixed location and predictable traffic load),  the
> features of deterministic and low energy consumption have definitely been
> provided. What we want to do is, with distributed reservation and RPL, the
> deterministic and low energy consumption features can be extended to the
> dynamic network (some degree of location change and/or some degree of
> traffic load change).****
>
> ** **
>
> Thought?****
>
> ** **
>
> Qin****
>
> ** **
>
> ** **
>
> ** **
>
> On Sat, Jul 27, 2013 at 12:20 AM, Pascal Thubert (pthubert) <
> pthubert@cisco.com> wrote:****
>
> Dear all;
>
> As you know, determinism and fast mobility are quite antagonistic in
> nature.
>
> Even with distributed routing, there are a number of issues like timeslot
> allocation and security context transfer or (re)establishment that will
> delay the mobility.
> In 6TSCH, we have use cases that we want to serve like the crane and the
> mobile handset, which require a certain degree of mobility but probably not
> make before break or sub-second reconnection. So we want to express that we
> aim at supporting this limited mobility but we do not want to raise the
> expectation higher than we can actually serve.
>
> The mobility term is so overloaded that it might be misleading. Would you
> have a suggestion for term that would be more appropriate?
>
> (I heard the terms soft, limited, and constrained so far)
>
> Cheers,
>
> Pascal
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>