Subject: [6tisch] minimal slotframe schedule

From: Xavier Vilajosana <[email-masked]>
Date: Sun, 9 Mar 2014 09:16:45 +0100

Hi all,
after plugfest discussion about slotframe dimensioning to avoid cases where
minimal configuration will not be able to handle network bootstrapping I
want to start a discussion about possible ways to address that.

I propose here a solution and I would like to hear your opinions.

Note that my point is to  to keep minimal draft as simple as possible so:

1) I propose to keep current configuration of slotframe indicating as a MUST
2) I propose to add a MAY/MIGHT section indicating that the slotframe
configuration MAY have more active slots (not mandatory) and dimensioned
according to the network degree and traffic requirements (To decide the
exact formula).

Nodes will use EBs to advertise Slotframe configuration (the MUST part).
The problem will come when there are a lot of MAY slots, but I think this
is a general issue in IEEE802.15.4e and should be addressed in the same way
as in 15.4e.

regards,
Xavi

---

From: Grieco <[email-masked]>
Date: Mon, 10 Mar 2014 21:39:43 +0100

Hi Xavi,

I am ok with the MAY section, but we also spoken about the slotframe length, which should be tuned based on the clock drift. Right ?

Cheers
Al

--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
Mobile: +39 3346715672

> Il giorno 9 Mar 2014, alle ore 09:16, Xavier Vilajosana <[email-masked]> ha scritto:
> 
> Hi all,
> after plugfest discussion about slotframe dimensioning to avoid cases where minimal configuration will not be able to handle network bootstrapping I want to start a discussion about possible ways to address that. 
> 
> 2) I propose to add a MAY/MIGHT section indicating that the slotframe configuration MAY have more active slots (not mandatory) and dimensioned according to the network degree and traffic requirements (To decide the exact formula).
> 
> Nodes will use EBs to advertise Slotframe configuration (the MUST part). The problem will come when there are a lot of MAY slots, but I think this is a general issue in IEEE802.15.4e and should be addressed in the same way as in 15.4e.
> 
> regards,
> Xavi
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 10 Mar 2014 22:26:07 +0100

Hi Alfredo,

I think there are 2 points here:

1-depending on the clock drift of a particluar device, a slotframe having
the active slots at the beginning might not be sufficient for it to keep
synchronization (i.e if their clocks drift more than 1ms in 101slots (1.5s
according to minimal draft)

2-depending on the number of nodes in the network (degree) and the active
slots, nodes might have a hard time keeping synchronization if collisions
occurr.

Here again I don't want to fall into a common miss-understanding, these
networks in practice are not super dense and the number of nodes in a
collision domain is not enourmous, note that 101 slots of 15ms can handle
more than 66 packets per second at the dagroot if all slots are active and
we have a perfect schedule. Using slotted aloha we have 36.8% efficiency in
the best case which leads to 25 packets per second. If we think in a
regular application using that technology we can find hundreds of nodes
sending a data packet once every 5 minutes + some control signaling to keep
synchronization, which is not a lot of traffic at the end.

I put that on the table because I do not want to complicate things
innecessarily, but in case this is needed, we can add a clause indicating
that slotframe MUST be 101 slots or optionally it can be larger but always
multiple of 101 slots so faster networks can still talk to slower ones.

this is a think that needs further discussion for sure.

X

2014-03-10 21:39 GMT+01:00 Grieco <[email-masked]>:

> Hi Xavi,
>
> I am ok with the MAY section, but we also spoken about the slotframe
> length, which should be tuned based on the clock drift. Right ?
>
> Cheers
> Al
>
> --
> Il giorno 9 Mar 2014, alle ore 09:16, Xavier Vilajosana <
> [email-masked]> ha scritto:
>
> Hi all,
> after plugfest discussion about slotframe dimensioning to avoid cases
> where minimal configuration will not be able to handle network
> bootstrapping I want to start a discussion about possible ways to address
> that.
>

---

From: Grieco <[email-masked]>
Date: Mon, 10 Mar 2014 23:09:58 +0100

Ok Xavi, we all know this minimal configuration can work but being minimal one shouldn't expect it works in an optimal way. As also Pascal said, this could be thought as a kind of recovery mode useful for configuration purposes. In these conditions, i.e., recovery/configuration, of course, this minimal mode is much more than sufficient. In the other cases, everbody can run the optimizations he thinks are useful and doable.

Just one remark, I already talked about during the last August. The real issue is not the syncronization in general but the first syncronization (the joining phase). If a mote looses the synch, whatever the load, he has to wait several slotframes before hearing an EB on the frequency it is listening. If this mote is a leaf then this is not a main issue otherwise it may compromise a wide part of the network. Of course, this issue cannot be solved with a minimal configuration but we need to remember that the longer the slotframe the harder the joining phase becomes.

Cheers

Al

> Il giorno 10 Mar 2014, alle ore 22:26, Xavier Vilajosana <[email-masked]> ha scritto:
> 
> Hi Alfredo,
> 
> 1-depending on the clock drift of a particluar device, a slotframe having the active slots at the beginning might not be sufficient for it to keep synchronization (i.e if their clocks drift more than 1ms in 101slots (1.5s according to minimal draft)
> 
> 2-depending on the number of nodes in the network (degree) and the active slots, nodes might have a hard time keeping synchronization if collisions occurr.
> 
> Here again I don't want to fall into a common miss-understanding, these networks in practice are not super dense and the number of nodes in a collision domain is not enourmous, note that 101 slots of 15ms can handle more than 66 packets per second at the dagroot if all slots are active and we have a perfect schedule. Using slotted aloha we have 36.8% efficiency in the best case which leads to 25 packets per second. If we think in a regular application using that technology we can find hundreds of nodes sending a data packet once every 5 minutes + some control signaling to keep synchronization, which is not a lot of traffic at the end.
> 
> I put that on the table because I do not want to complicate things innecessarily, but in case this is needed, we can add a clause indicating that slotframe MUST be 101 slots or optionally it can be larger but always multiple of 101 slots so faster networks can still talk to slower ones.
>

---

From: Qin Wang <[email-masked]>
Date: Tue, 11 Mar 2014 07:09:54 -0700 (PDT)

Hi Xavi and all,

In the current version, it is said "The suggested minimal schedule may be hard-coded in each node." which leads to that scheduling the MUST slots is really different from scheduling the MAY slots, because the second one has to include TSCH Slotframe&Link IE in EB. 

But, I would like to go back one step and ask "Should supporting TSCH EB with TSCH Slotframe&Link IE be mandatory in minimal draft?" . I understand that the negative answer will make implementation simple. But, the positive answer can unify scheduling both the MUST slots and MAY slots. In fact, supporting TSCH EB with TSCH Slotframe&Link IE is the function of 15.4e, therefore, a assumption of 6tisch minimal.

What do you think?

Thanks
Qin

On Tuesday, March 11, 2014 5:26 AM, Xavier Vilajosana <[email-masked]> wrote:
 
Hi Alfredo,

X

Hi Xavi,

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 12 Mar 2014 11:33:08 +0100

Hi Qin, all,

the minimal draft states that the pre-configured slots are advertised in
the EB as part of the  Slotframe&Link IE so joining nodes not implementing
minimal can always learn that basic configuration.

The problem comes when we add the MAY part with several more slots.
The  Slotframe&Link
IE  will grow several bytes for each cell we advertise. As our packets are
127bytes long we cannot advertise a lot of slots, so here we face a
problem. How do we do that?

I gues that the Slotframe&Link IE is not designed tp ne used as an
scheduling mechanism but as a boostrap mechanism with little slots on it.
Thomas, what is your point here?

regards,
Xavi

2014-03-11 15:09 GMT+01:00 Qin Wang <[email-masked]>:

> Hi Xavi and all,
>
> In the current version, it is said "The suggested minimal schedule may be
> hard-coded in each node." which leads to that scheduling the MUST slots is
> really different from scheduling the MAY slots, because the second one has
> to include TSCH Slotframe&Link IE in EB.
>
> But, I would like to go back one step and ask "Should supporting TSCH EB
> with TSCH Slotframe&Link IE be mandatory in minimal draft?" . I understand
> that the negative answer will make implementation simple. But, the positive
> answer can unify scheduling both the MUST slots and MAY slots. In fact, supporting
> TSCH EB with TSCH Slotframe&Link IE is the function of 15.4e, therefore, a
> assumption of 6tisch minimal.
>
> What do you think?
>
> Thanks
> Qin
>
>