Great, Tengfei
This is very much what I was asking for.
Regards,
Pascal
Le 9 août 2019 à 13:05, Tengfei Chang
mailto:tengfei.ch...@gmail.com>> a écrit :
Thanks Tero and Pascal for the comments!
I understand What Pascal and Tero are saying. According to the discussion above
and during the I
Thanks Tero and Pascal for the comments!
I understand What Pascal and Tero are saying. According to the discussion
above and during the IETF 105 6TiSCH meeting, I would add the following
content in the next version of the draft in Rule of Celllist section:
Since the Cell is randomly selected, th
Pascal Thubert (pthubert) writes:
> In a 6TiSCH network, CCA is useless between synchronized devices because
> they’ll talk at the same time. So LBT must be done some other way.
Note, that 802.15.4 do allow doing CCA if TschCca was set on when
MLME-TSCHE-MODE.request primitive is called to turn TS
draft and make it optional.
All the best,
Pascal
From: Tengfei Chang
Sent: mercredi 17 juillet 2019 08:32
To: Pascal Thubert (pthubert)
Cc: 6tisch@ietf.org
Subject: Re: [6tisch] call for review: draft-ietf-6tisch-msf-04
Hi Pascal,
It is good for me to confirm it is about the hidden terminal
and
> inefficient. If the cells are not used a lot it will take time. I disagree
> that it can be the sole procedure to avoid collisions.
>
>
>
> All the best,
>
>
>
> Pascal
>
>
>
> *From:* Tengfei Chang
> *Sent:* mercredi 17 juillet 2019 06:12
>
Hi Esteban,
Thanks for the comments, I will answer inline:
On Thu, Jul 11, 2019 at 3:47 PM Esteban Municio <
esteban.muni...@uantwerpen.be> wrote:
> Hi Tengfei,
>
> I like the new changes, especially the concept of autonomous cells by
> demand and always having by default 1 downlink negotiated c
ent: mercredi 17 juillet 2019 06:12
To: Pascal Thubert (pthubert)
Cc: 6tisch@ietf.org
Subject: Re: [6tisch] call for review: draft-ietf-6tisch-msf-04
Hi Pascal,
For the synchronization, I agree. It should be listening for a certain period
of time and then choose which EB to use for synchronizing. W
Hi Pascal,
For the synchronization, I agree. It should be listening for a
certain period of time and then choose which EB to use for synchronizing.
Will update in the next version.
For the rule of celllist:
- > Not the same problem. Think about this, where does the list of free
cells come
Hi Esteban,
> * Maybe out of the scope but, should not be defined here a housekeeping
> function that removes unused negotiated cells (TX or RX)? For example
> for cells that can't be removed with a 6P transaction (e.g. nodes are
> not in range any more).
It'd be nice to mention something there,
Hi Tengfei,
I like the new changes, especially the concept of autonomous cells by
demand and always having by default 1 downlink negotiated cell.
Here are some minor comments (checking msf-05):
* In Section 5.2, it is not clear for me if the parent switch occurs
before, during or after the 3-st
Hello Tengfei
I think you missed my points
>The text was not expected to become normative as is; obviously the usual
> ways apply like time out if some but not all beacons are received and sync to
> the best.
>
Yes, I agree with what you said, I replied with a wrong typing word. What I
Hi Pascal,
On Mon, Jul 8, 2019 at 3:08 PM Pascal Thubert (pthubert)
wrote:
> Hello Tengfei
>
> tions address is correct. Thanks!
>
>
>
>
>
> “
>
>During this step, the pledge MAY synchronize to any EB it receives
>
>from the network it wishes to join.
>
> “
>
> In TSCH, time creates an e
Hello Tengfei
tions address is correct. Thanks!
“
During this step, the pledge MAY synchronize to any EB it receives
from the network it wishes to join.
“
In TSCH, time creates an event horizon whereby one only hears transmissions
that start during guard time around the scheduled Rx time
| (NOTE:this) |
>
>
>
> “
>
>- maybe
>
>
>
>| IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFC_THIS|
>
>| | (MSF) | |
>
Will be applied in the next version!
t;
>
>
> Although managing the counters for each neighbor is conceptually
>
> simple, I admit it might be too much overhead for constrainted nodes.
>
Thanks for the comments! However, along the network time, the node won't
send upper layer packet s to non-parent neighbor.
In case o
Thanks a lot Yatch for reviewing the draft. I will reply inline:
On Tue, Jul 2, 2019 at 2:58 PM Yasuyuki Tanaka
wrote:
> Thank you, Tengfei and the other authors, for the update!
>
> Here are my comments:
>
> [Major] Negotiated RX cell (Section 4.6)
>
> https://tools.ietf.org/html/draft-ietf-6ti
nimal Scheduling Function | RFC_THIS|
| | (MSF) | |
All the best,
Pascal
From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Tengfei Chang
Sent: mardi 2 juillet 2019 12:57
To: 6tisch@ietf.org
Subject: [6tisch] call for review: draft-ietf-6tisch-msf-04
Hi Tengfei,
Another minor comment:
https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-5.3
draft> 5.3. Handling Schedule Collisions
draft>
draft> A node implementing MSF SHOULD implement the behavior described in
draft> this section. The "MUST" statements in this section hence only app
nceptually
simple, I admit it might be too much overhead for constrainted nodes.
BTW, there are still two occurrences of "managed unicast cell" in the
draft.
Best regards,
Toshio Ito
From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Tengfei Chang
Sent: Tuesday, July 02, 2019 7:57
Thank you, Tengfei and the other authors, for the update!
Here are my comments:
[Major] Negotiated RX cell (Section 4.6)
https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.6
If MSF is designed for regular upstream traffic, I don't think we need
the negotiated RX cell that is introdu
Dear all,
As you may noticed that a new version of MSF is just published at here:
https://tools.ietf.org/html/draft-ietf-6tisch-msf-04
There are some moderate changes comparing to previous one.
Mainly in two aspects:
1. change the concept of autonomous cell
In the new version, there will be two
21 matches
Mail list logo
