[6tisch] AD evaluation: draft-ietf-6tisch-minimal-16

[as I happen to have 802.15.4-2015 open, here are suitable references to it...] Suresh Krishnan writes: > Section 3: > > CCA: Clear Channel Assessment. > > - Can you provide a description or a reference? This is not in the > terminology document. Is this the same CCA as WiFi? CCA for TSCH is

[6tisch] contradiction in 6P draft

Per Diego's presentation There is a contradiction on the 6P draft, first saying that the SF MAY define the timeout on section 4.1.1 and then that the SF MUST define the timeout on section 5.2 6P authors, can you please fix? -- ___ Thomas Watteyne, PhD

[6tisch] AD evaluation: draft-ietf-6tisch-minimal-16

Hi authors, I went through the latest version of the draft and it is almost ready to go. There are a few issues that I would like to see fixed before I progress it and I have detailed them in this mail. Section 3: CCA: Clear Channel Assessment. - Can you provide a description or a

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Hi Diego and Tengfei, diego> I suggest to keep the CLEAR command after reboot/failure. It's fine for me, too. tengfei> I am thinking another case that a node needs send a CLEAR tengfei> command to previous parent if it changed. I guess this is not tengfei> mentioned in the draft? No, it's not

Re: [6tisch] Shared / Dedicated cell policy on SF0

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

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

That would be perfect, thanks! On Thu, 17 Nov 2016 at 00:11 Prof. Diego Dujovne wrote: > Thomas, > It is not on my slides, since the default > behavior (issue a CLEAR command) did not > change from -01 to -02. I can raise the issue > during the

Re: [6tisch] Shared / Dedicated cell policy on SF0

Yatch, Allow me to answer in two parts. First, about your last statement, I don't think CCA will make a difference. Since the nodes are synchronized, they will all be doing the CCA at the same time and not hear each other. If I get your first point well, you suggest to schedule shared cells so

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Thomas, It is not on my slides, since the default behavior (issue a CLEAR command) did not change from -01 to -02. I can raise the issue during the presentation. Regards, Diego 2016-11-16 12:06 GMT-03:00 Thomas Watteyne : >

Re: [6tisch] Node Address of Cell

Synchronized is a good thing in a 6TiSCH world :-) On Wed, 16 Nov 2016 at 19:56 Yasuyuki Tanaka wrote: > Hi Tero, > Thank you for the clear explanation!! > > I check Figure 6-5 and Figure 6-6 that you referred. Indeed, there is > no distinction on a sending frame

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Diego, Fine for me. Could you bring it up during the WG meeting tomorrow? Thomas On Thu, 17 Nov 2016 at 00:02 Prof. Diego Dujovne wrote: > Yasuyuki, Thomas, > I suggest to keep the CLEAR command > after reboot/failure. > Regards, > >

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Yasuyuki, Thomas, I suggest to keep the CLEAR command after reboot/failure. Regards, Diego 2016-11-16 11:05 GMT-03:00 Thomas Watteyne : > @Tengfei, > Does that suggestion work for you or should we

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

@Yatch, I see the point. I have no doubt now about the behaviors after the node boot. I am thinking another case that a node needs send a CLEAR command to previous parent if it changed. I guess this is not mentioned in the draft? @Thomas, maybe we can create an issue for that? Let me know if

Re: [6tisch] Malware in IoT/WSN with 6tisch + Clock Drift

Gregory, Excellent, I get much better what you are trying to do. Allow me to take this discussion off-list, as not directly related to the standardization work at 6TiSCH. Thomas On Wed, Nov 16, 2016 at 11:33 PM, Gregory Braekevelt < gregory.braekev...@student.kuleuven.be> wrote: > Dear mr

Re: [6tisch] Malware in IoT/WSN with 6tisch + Clock Drift

Dear mr Watteyne I'll explain why the question is relevant for me. I am researching the possibility whether I can use the tight synchronisation of TSCH in a network of sensors/nodes to detect the presence of malware for research for a master thesis. What kind of malware it is, doesn't

Re: [6tisch] [6TISCH] RELOCATE command in sixtop?

I gather from this thread that there is a consensus on adding a RELOCATE command to 6P. I suggest we create an issue to capture this and take a minute from the 6P presentation at the WG meeting tomorrow to gather feedback from the room. On Thu, Nov 3, 2016 at 12:45 AM, Nicola Accettura

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

@Tengfei, Does that suggestion work for you or should we create an issue on SF0? Thomas On Fri, Nov 11, 2016 at 8:50 PM, Yasuyuki Tanaka < yasuyuki9.tan...@toshiba.co.jp> wrote: > Hi Tengfei, > > I think an assumption there is that a node has no state with its > neighbors just after booting up

Re: [6tisch] Node Address of Cell

Hi Tero, Thank you for the clear explanation!! I check Figure 6-5 and Figure 6-6 that you referred. Indeed, there is no distinction on a sending frame between unicast or broadcast. Now I've got synchronized. :-) Best, Yatch On 2016/11/16 4:05, Tero Kivinen wrote: Yasuyuki Tanaka writes: In