MAC coordinator (typically also t= he time source)

_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch

Hello:

At the call we decided we'd have an informal meeting (a Bar BOF) at the IETF.
I prepared a doodle to select the best time for everyone
http://doodle.com/svi7uc9ezrx5w9dg

Please fill it up soon, since we need to select that time to socialize
with the ADs early.

Cheers,

Hello:

At the call we decided we'd have an informal meeting (a Bar BOF) at th=
e IETF.
I prepared a doodle to select the best time for everyone
http://doodle.com/svi7u=
c9ezrx5w9dg

Please fill it up soon, since we need to select that time to socialize=

with the ADs early.

Cheers,

Hello:
=A0
At the call we decided we'd have an informal meeting (a Bar BOF) a=
t the IETF.
I prepared a doodle to select the best time for everyone=

http:=
//doodle.com/svi7uc9ezrx5w9dg
=A0
Please fill it up soon, since we need to select that time to socialize=

with the ADs early.
=A0
Cheers,
=A0

_______________________________________________
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
h=
ttps://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
6tsch@=
ietf.orghttps://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
6tsch@ietf.orghttps://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

_______________________________________________
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

_______________________________________________=0A=
6tsch mailing list=0A=
6tsch@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/6tsch<=
/a>=0A=

_______________________________________________
> 6tsch mailing list
>  href="mailto:6tsch@ietf.org">6tsch@ietf.org
>  href="https://www.ietf.org/mailman/listinfo/6tsch">https://www.ietf.org/mailman/listinfo/6tsch
> 
> 
> _______________________________________________
> 6tsch mailing list
>  href="mailto:6tsch@ietf.org">6tsch@ietf.org
>  href="https://www.ietf.org/mailman/listinfo/6tsch">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
h=
ttps://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
6tsch@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
6tsch@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/6tsch

___________________________________________=
____
6tsch mailing list
6tsch@ietf.org<=
/pre>https://www.ietf.org/mailman/listinfo/6tsch

 =
_______________________________________________=
6tsch mailing list
6tsch@ietf.org
https://www.ie=
tf.org/mailman/listinfo/6tsch
_______________________=
________________________
6tsch mailing list
6tsch@ietf.org
https://=
www.ietf.org/mailman/listinfo/6tsch
=A0=

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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.ie=
tf.org/mailman/listinfo/6tsch
_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ie=
tf.org/mailman/listinfo/6tsch
Hi Pascal,

Just some idea popping out. I think we can use queue with priority in 6tus
to provide support to QoS. The following is some related detail.

(1)The communication schedule in TSCH can be abstracted as 2-D array, some
of its elements are marked as TX, RX. My understanding is the array could
be a result of overlapping multiple slotframes. Therefore, I think it is
not easy to associate slots, i.e. the elements in the array, with
priority.

(2)But, 6tus can provide support to QoS in this way: 6tus maintains some
queues with different priority, and put control/data packets with priority
from upper layer into corresponding queues, and feeds those packets into
TSCH according to some QoS policy. TSCH works just like before,
transmitting packet in Tx slot without knowing its priority.

Does it make sense?

Qin

Hi Xavi and Maria-Rita:

We may find a number of asynchronous types. I can see:

1) RPL signaling, highest priority
2) best effort traffic, lowest priority and with no reservation at all,
for lesser importance sensors like corrosion.
3) lazy reservation overflow, when a small jitter is acceptable. Virtual
bandwidth was reserved but physical slots are only allocated upon observed
use.

For all 3, transmission is statistical, and all 3 will be governed by QoS
as opposed to reservation.

So basically we'll probably need some time slots with priority to
accommodate either parent to any child (shared reception slot though a
given packet may be unicast) or any child to parent (shared emission with
contention) traffic.

Is that doable?

Pascal

-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of
Maria Rita PALATTELLA
Sent: mardi 26 février 2013 08:55
To: Xavier Vilajosana; 6tsch@ietf.org
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Hello Xavi,
from my point of view, having a TSCH broadcast channel could be useful in
several situations:

a) ADV need broadcast channels in case they are used to synchronize the
network. IEEE 802.15.4e provides the timekeeping flag to set that
channels as used for synchronization and shared flag can make them
broadcast.
b) Those networks that do not need ADV for synchronization then can use
any TX link for ADV, this means that if it is not shared only the node
listening on that link will get the ADV. However as this periodically
occurs the ADV might eventually be listened  >>>in all channels.

1) synchronization (as you said in [a]): it will allow to have a faster
set-up phase for synchronizing all the motes in the network. While, using
any TX link ([b]), even though this will hop from one channel to another,
it will imply a longer set-up phase, because each mote will be able to
synchronize at a different time (when it is in listen mode on the "right"
channel).

c)Some DAOs and all DIOs require a broadcast channel. Should the
schedule provide that? in case of a), can the same link be used? How
this link should be installed in the nodes?

2) transmission of RPL messages (DAOs and DIOs). If we want TSCH works
with RPL, then we should reserve some slots of the schedule for exchanging
information between L3 and L2. I am not sure we should use the same link
used for synchronization, maybe it could be better to have 2 different
ones, dedicated to different purposes. Anyway, this is something to check.

d)Is the scheduler of the network who should setup a broadcast channel
independent of the broadcast channel set for ADV? can it be the same?
Or in contrast, 6tus can configure the EB so it indicates a broadcast
channel..

3) transmission of signaling messages for setting up the schedule. Let's
assume there is a scheduler that builds the schedule for the network. In
order to assign some links to each of them, it  will need to broadcast the
information related to ( timeOffset, ChannelOffset). As for the
synchronization, having a broadcast channel dedicated to the signaling
will allow to set up the schedule in shorter time.

Maybe, because there are 16 available channels in  IEEE802.15.4/15.4e PHY,
using some of them as broadcast channels for synchronization/exchange of
cross-layer info/set up of the schedule wouldn't  be a big problem. In
many applications, a smaller set of channels (< 16) will be enough for
building a reliable schedule.

6tus, as adaptation layer, may have a key role in the configuration of
such broadcast channels, but we will need to think  "how/when" it should
take care of that.

For now, let's see what other 6tus members think about!

Maria Rita

-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of
Xavier Vilajosana
Sent: Tuesday, February 26, 2013 5:16 AM
To: 6tsch@ietf.org
Subject: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Hi,

I have a question that i want to discuss, the question is whether we need
a broadcast channel in TSCH or not and what kind of support 6tus should
provide. (the answer can be depends... but lets see some cases)

a) ADV need broadcast channels in case they are used to synchronize the
network. IEEE 802.15.4e provides the timekeeping flag to set that channels
as used for synchronization and shared flag can make them broadcast.
b) Those networks that do not need ADV for synchronization then can use
any TX link for ADV, this means that if it is not shared only the node
listening on that link will get the ADV. However as this periodically
occurs the ADV might eventually be listened in all channels.
c)Some DAOs and all DIOs require a broadcast channel. Should the schedule
provide that? in case of a), can the same link be used? How this link
should be installed in the nodes?
d)Is the scheduler of the network who should setup a broadcast channel
independent of the broadcast channel set for ADV? can it be the same? Or
in contrast, 6tus can configure the EB so it indicates a broadcast
channel..
e)..

I would like to know what is your opinion on that.

cheers!
Xavi
_______________________________________________
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

_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch

Safety	Class 0: Emergency action	Always critical
Control	Class 1: Closed loop regulatory control	Often critical
	Class 2: Closed loop supervisory control	Usually non-critical
	Class 3: Open loop control	Human in the loop
Monitoring	Class 4: Alerting	Short-term operational consequence (e.g., event-based maintenance)
Monitoring	Class 5: Logging and downloading / uploading	No immediate operational consequence (e.g., history collection, sequence-of-events, preventive maintenance)
NOTE Batch levels[1] 3 and 4 could be class 2, class 1 or even class 0, depending on function.


Pascal Thubert IPv6 Engineering pthuber= t@cisco.com Phone :+33 497 23 26 34 Mobile :+33 619 98 29 85	Cisco Systems Building D, 45 Allee des Ormes 06250 MOUGINS France Cisco.com

Think before you print. This email may con= tain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by = others is strictly prohibited. If you are not the intended recipient (or au= thorized to receive for the recipient), please contact the sender by reply = email and delete all copies of this message. For corporate lega= l information go to: http://www.ci= sco.com/web/about/doing_business/legal/cri/index.html