Michel and Nicola,
Firstly, I agree It could be a good idea to let DATA/ACK frames carry softcell
negotiation information, and agree it belongs to 6top-to-6top negotiation
procedure, instead of OTF.
Secondly, I would like to compare the two following schemes to implement the
idea.
(1) nodeA sends a data frame to nodeB with Frame Pending setting; nodeB reply a
ACK frame, with a softcell request response IE to give nodeA additional
softcell to send its following data frame.
(2) nodeA send a data frame to nodeB, in which a softcell request IE is
carried; nodeB reply a ACK frame, with a softcell request response IE to give
nodeA additional softcell to send its following data frame.
I prefer scheme (2) although it costs more bits of softcell request IE from
nodeA to nodeB, because Frame Pending bit belongs to MAC layer, it indicates
there is more data following, not necessarily more bandwidth will be needed.
The remained issue for both of the schemes is if the time for nodeB to insert
the softcell request response IE into ACK frame is too tight or not. I don't
have clear answer to it.
What do you think?
ThanksQin
On Thursday, July 2, 2015 2:05 AM, Nicola Accettura
<[email protected]> wrote:
Qin,
you are pointing out that the bandwidth must be already provided if one wants
to use the Frame Pending setting. This is what we have discussed in the past
and is the state of the art in 6tisch.
Michele is proposing to use the Frame Pending jointly with a temporary cell
reservation in the ACK.
I guess this is not in the scope of OTF, but, in case, in that of
6top-to-6top. Why?
Currently 6top-to-6top could be used for allocating cells through a negotiation:
- mote A sends a reservation request to mote B in a cell, and that signaling
packet is unicast, so acknowledged in the same cell by B
- mote B answers A with a reservation response in a following cell, which is
also a unicast packet acnowledged in that same cell
Michel is saying:
- mote A sends a Frame Pending to B in a cell, and B sends the ack to A in
the same cell answering with a temporary allocation
So, Michel's proposal uses 1 cell to perform the negotiation that 6top does (in
the current version) by using 2 cells. I guess this is the reason for defining
this approach reactive.
At the same time, the current 6top negotiation allows to exchange more
information for reserving a common available cell. In Michel's approach I
figure out many cases of failures: what happens if the temporary cell given by
B to A was already busy in A (it was already part of the A's schedule, but with
another neighbor, say C)? I guess A will not be able to free its memory, so
leading to congestion. Right?
Nicola
2015-07-01 10:09 GMT-07:00 Michel Veillette <[email protected]>:
Hi Qin Yes, the Frame Pending flag is defined as follow: IEEE 802.15.4-2006
section 7.2.1.1.3“Frame Pending subfield is 1 bit in length and shall be set to
one if the device sending the frame has more data for the recipient. This
subfield shall be set to zero otherwise” This feature can be especially useful
for the upstream traffic in a RPL DODAG. In a scenario where a DAG parent have
dozens of children, dedicated timeslot will be infrequent and share timeslots
suffer from contention. If a subset of these children have ongoing traffic, the
parent can use the Frame Pending flag information to schedule temporary soft
cells and avoid contention or speedup transfer.
| | Michel Veillette
System Architecture DirectorTrilliant Inc.
Tel: 450-375-0556 ext. 237
[email protected] |
From: Qin Wang [mailto:[email protected]]
Sent: 1 juillet 2015 11:28
To: Nicola Accettura; Michel Veillette
Cc: [email protected]; [email protected]
Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05 Hi Michel and Nicola,
I think Michel's idea is interesting. But, according to my understanding, the
Frame Pending setting just means there is frame following, does not mean that
the current bandwidth provided by TSCH schedule, including hard cells and soft
cells, is not enough to convey those frames, and then needs more bandwidth
(e.g. additional soft cells) . Right? Do I miss something? ThanksQin On
Wednesday, July 1, 2015 4:03 AM, Nicola Accettura <[email protected]>
wrote: Hi Michel,your proposal is very interesting.
However, OTF does not allocate cells directly: it just computes the estimated
number of cells to add or delete into the schedule, and then sends this
information to 6top. 6top is then in charge of negotiating cells among
neighbors, and meybe perform the scheme you are proposing.
So, your proposal seems fitting more the 6top-to-6top communication.Am I
missing something? What others think about?SincerelyNicola 2015-06-30 8:13
GMT-07:00 Michel Veillette <[email protected]>:
Hi Diego It’s my first reading of the “6TiSCH On-the-Fly Scheduling” (and I’m
not completely done yet) and I wandering if the concept of on the fly, in a
single exchange, temporary allocation of a soft cell have already been
discussed. For example, a node can use the Frame Pending subfield (IEEE
802.15.4-2006 section 7.2.1.1.3) to indicate the presence of packets ready to
be transmitted. Based on that knowledge, the target may add an IE in an
enhanced acknowledgment to allocate a temporary soft cell (e.g. single cell).
Each subsequent transmission may further re-allocate a temporary soft cell.
It’s important to note that the default delay for a TSCH Acknowledgment is 1ms
(macTsTxAckDelay) which seem sufficient for the processing of this new IE.
This scheme is very reactive and may help dealing with non-predictable
communication patterns.What do you things?
| |
| Michel Veillette
System Architecture DirectorTrilliant Inc.
Tel: 450-375-0556 ext. 237
[email protected] |
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
