Hi Thomas and Diego,
thomas> Since the nodes are synchronized, they will all be doing the
thomas> CCA at the same time and not hear each other.
Oh yeah. There is no random delay before performing CCA in the TSCH
case in Figure 6-5 of IEEE 802.15.4-2015! OK, I understand that two
TSCH TX devices sharing a single TX cell will send their frames at the
same time after CCA.
But, what if there are devices of other types or protocols? CCA could
prevent a TSCH device from disturbing other ongoing communication by
non-TSCH devices. Performing CCA could make 6TiSCH/TSCH devices a bit
nicer to other devices at the cost of energy for CCA.
How about defining a configuration parameter to control which type of
cell to schedule, dedicated or shared? I guess, SF0 cannot make such a
decision autonomously, so let's leave it to network administrators or
users.
# We would still have to decide its default value, though.
If they know there are only TSCH-aware nodes, for example, in a
managed environment, CCA is not needed; disable CCA so that the nodes
can save energy. Otherwise, CCA is enabled.
thomas> I would argue that, because packets get lost anyways in
thomas> wireless from time to time, a node might end up backing off
thomas> more than necessary. I don't have numbers to prove, but since
thomas> there schedules are typically verse sparse, backing off might
thomas> cost you more than not.
I agree. It would take a long time to get a next chance to send with a
sparse cell schedule. We may have to set 0 to macMaxFrameRetries to
avoid backoffs when using shared TX cells in TSCH; then, the case of
performing CCA in the CSMA-CA algorithm looks compatible with the
other case from the point of view of an upper layer, e.g., 6TiSCH.
Best,
Yatch
On 2016/11/16 16:22, Prof. Diego Dujovne wrote:
Yakusuki,
We currently assume that:
- we have no information about the generated traffic from the application
- we do not know which part of the incoming traffic is routed to which
neighbour.
Example: If a both a TX cell and a Shared cell are requested as incoming
to the node, we do not know to which neighbour these cells will be routed,
or if the incoming traffic destination is the node itself.
As a consequence, since the only true source of information is the effective
number of outgoing cells, our default behavior is to allocate dedicated TX cells
to the specific neighbour.
I think the reason to use TX or Shared cells as a default, is covered by
Thomas' answer.
Thank you.
Regards,
Diego
2016-11-16 8:33 GMT-03:00 Yasuyuki Tanaka <[email protected]
<mailto:[email protected]>>:
Hi Diego,
diego> b) if we keep working with the initial assumption, and do not
diego> allow any shared cells to be scheduled by SF0.
Why is scheduling shared cells not allowed by the initial assumption?
I'm a relative newcomer to 6TiSCH and not sure about the initial
assumption...
To me, it seems that scheduling shared cells is more sensible in
Neighbor-to-Neighbor Scheduling than dedicated cells. I would say that
the SHARED cell bit in the CellOptions field should be always on when
the field is used for CMD_ADD.
A pair of devices in a 6P conversation have no idea if cells they are
scheduling are truly dedicated. In general, cells scheduled with 6P
are possibly shared with multiple TX devices. In other words, I think
it'd be better to always perform CCA on a cell scheduled with 6P.
Best,
Yatch
On 2016/10/31 22:23, Prof. Diego Dujovne wrote:
Dear all,
SF0 has assumed until now that it was
only working on dedicated cells, but 6P now provides
the possibility to use shared cells.
I would like to hear your thoughts on the
following alternatives:
a) if we allow shared cells to be used SF0, how to
establish a policy on which type of cells to allocate.
Currently, SF0 observes only the incoming number of
cell allocation requests and effectively used cells
to calculate the number of required cells.
b) if we keep working with the initial assumption, and
do not allow any shared cells to be scheduled by SF0.
A quick solution would be to define two different instances
of SF0, one for shared cells and the other for dedicated
ones.
Regards,
Diego
--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl <http://www.ingenieria.udp.cl>
<http://www.ingenieria.udp.cl>
(56 2) 676 8125
_______________________________________________
6tisch mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
<https://www.ietf.org/mailman/listinfo/6tisch>
--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl <http://www.ingenieria.udp.cl>
(56 2) 676 8125
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
