Re: [riot-devel] Association time in mobile RPL/6lowpan networks

[Joakim Gebart]

On May 21, 2015 8:37 AM, "Cenk Gündogan" 
wrote:
>
> Hey Adam,
>
> I am currently adopting RPL to our new network stack and while doing so,
> I also added sane functionalities which were plainly missing in the old
implementation.
> This also includes sending a DIS when initializing RPL for the first time.
> However,  I am just now realizing that such a DIS can get lost in our
typical LLN case - it may make sense to send a DIS periodically until a DIO
is received?
> Does anyone has an opinion on this?

Good idea, as long as the periodic interval is large enough to not waste
power or cause interruptions in normal traffic if there is no other rpl
node on the network.

>
> Forcing a DIS from userspace sounds like a good feature. It may help in
testing/debuging the dodag tree interactively.
> I also thought about reseting the trickle timer from userspace to enforce
DIOs.

+1 for this. It would be nice to have some shell commands to call these
functions too.

Best regards,
/Joakim

>
> Cheers,
> Cenk
>
>
> On 21.05.2015 04:36, Adam Hunt wrote:
>>
>> That's great. Is there any way to force a node to send a DIS message
from userspace?
>>
>>
>> On Wed, May 20, 2015, 5:34 PM Oleg Hahm  wrote:
>>>
>>> Hi Adam!
>>>
>>> > Has anyone tested the amount of time it takes for a node (full or
reduced
>>> > function) to join an RPL routed 6lowpan network? I realize that it's
very
>>> > likely to vary quite a bit depending on the network, I'm just curious
if
>>> > anyone has an approximate range.
>>>
>>> As you said: it depends quite a bit on the network and the parameters.
Since
>>> nodes on the current RPL implementation won't send proactively DIS
messages
>>> and the interval of sending DIOs increases, it will usually take just a
couple
>>> of seconds if you try to join the network right after bootup, but can
take
>>> more than one minute in a later phase.
>>>
>>> Cheers,
>>> Oleg
>>> --
>>> printk (KERN_ERR "%s: Oops - your private data area is hosed!\n", ...)
>>> linux-2.6.6/drivers/net/ewrk3.c
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Association time in mobile RPL/6lowpan networks

[Cenk Gündogan]

Hey Adam,

I am currently adopting RPL to our new network stack and while doing so,
I also added sane functionalities which were plainly missing in the old 
implementation.

This also includes sending a DIS when initializing RPL for the first time.
However,  I am just now realizing that such a DIS can get lost in our 
typical LLN case - it may make sense to send a DIS periodically until a 
DIO is received?

Does anyone has an opinion on this?

Forcing a DIS from userspace sounds like a good feature. It may help in 
testing/debuging the dodag tree interactively.
I also thought about reseting the trickle timer from userspace to 
enforce DIOs.


Cheers,
Cenk

On 21.05.2015 04:36, Adam Hunt wrote:


That's great. Is there any way to force a node to send a DIS message 
from userspace?



On Wed, May 20, 2015, 5:34 PM Oleg Hahm > wrote:


Hi Adam!

> Has anyone tested the amount of time it takes for a node (full
or reduced
> function) to join an RPL routed 6lowpan network? I realize that
it's very
> likely to vary quite a bit depending on the network, I'm just
curious if
> anyone has an approximate range.

As you said: it depends quite a bit on the network and the
parameters. Since
nodes on the current RPL implementation won't send proactively DIS
messages
and the interval of sending DIOs increases, it will usually take
just a couple
of seconds if you try to join the network right after bootup, but
can take
more than one minute in a later phase.

Cheers,
Oleg
--
printk (KERN_ERR "%s: Oops - your private data area is hosed!\n", ...)
linux-2.6.6/drivers/net/ewrk3.c
___
devel mailing list
devel@riot-os.org 
https://lists.riot-os.org/mailman/listinfo/devel



___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Association time in mobile RPL/6lowpan networks

[Adam Hunt]

That's great. Is there any way to force a node to send a DIS message from
userspace?

On Wed, May 20, 2015, 5:34 PM Oleg Hahm  wrote:

> Hi Adam!
>
> > Has anyone tested the amount of time it takes for a node (full or reduced
> > function) to join an RPL routed 6lowpan network? I realize that it's very
> > likely to vary quite a bit depending on the network, I'm just curious if
> > anyone has an approximate range.
>
> As you said: it depends quite a bit on the network and the parameters.
> Since
> nodes on the current RPL implementation won't send proactively DIS messages
> and the interval of sending DIOs increases, it will usually take just a
> couple
> of seconds if you try to join the network right after bootup, but can take
> more than one minute in a later phase.
>
> Cheers,
> Oleg
> --
> printk (KERN_ERR "%s: Oops - your private data area is hosed!\n", ...)
> linux-2.6.6/drivers/net/ewrk3.c
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Association time in mobile RPL/6lowpan networks

[Oleg Hahm]

Hi Adam!

> Has anyone tested the amount of time it takes for a node (full or reduced
> function) to join an RPL routed 6lowpan network? I realize that it's very
> likely to vary quite a bit depending on the network, I'm just curious if
> anyone has an approximate range.

As you said: it depends quite a bit on the network and the parameters. Since
nodes on the current RPL implementation won't send proactively DIS messages
and the interval of sending DIOs increases, it will usually take just a couple
of seconds if you try to join the network right after bootup, but can take
more than one minute in a later phase.

Cheers,
Oleg
-- 
printk (KERN_ERR "%s: Oops - your private data area is hosed!\n", ...)
linux-2.6.6/drivers/net/ewrk3.c


pgpwb3HlfS14l.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Association time in mobile RPL/6lowpan networks

[Adam Hunt]

Has anyone tested the amount of time it takes for a node (full or reduced
function) to join an RPL routed 6lowpan network? I realize that it's very
likely to vary quite a bit depending on the network, I'm just curious if
anyone has an approximate range.

Thanks,

Adam Hunt
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] IEEE802.15.4 discovery

[Jonas Remmert]

Hi again ;),

We just opened an Issue [1] "802.15.4(e) MAC-Layer Task Force" where we 
can discuss further steps.


Even if this issue might be related to an 802.15.4(e) MAC-Layer, some 
parts of that could also be of interest for other (future) MAC-layer.


From our perspective an IEEE 802.15.4(e) MAC layer will be most 
beneficial. The most important points would be (i) official 
standardization and (ii) interoperatiblity (RIOT <-> other OS).


What would be your opinion on IEEE 802.15.4e. Is the amendment (e) a 
straight forward extension to the basic 802.15.4 standard or does this 
extention omit the basic mechanisms such as "beacon-mode" and the 
"superframe-architecture"?
Does it makes more sense to implement firstly an basic IEEE 802.15.4 and 
then the amendment (e) or begin directly with the amendment (e)? 
Reference for amendment (e) could be OpenWSN.


[1] - https://github.com/RIOT-OS/RIOT/issues/3039

Best
Johann, Jonas

On 20.05.2015 10:28, Hauke Petersen wrote:

Hi,

@Jonas, is your 802.15.4 MAC layer implementation planned to cope with 
this?


Cheers,
Hauke


On 19.05.2015 20:18, Kaspar Schleiser wrote:

Hey,

is anybody working on or are there plans for support for discovering
802.15.4 PANs?

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Biweekly virtual meeting

[Peter Kietzmann]

Sorry, you can find the instructions for joining in this link :-) :

https://github.com/RIOT-OS/RIOT/wiki/Instructions-for-remote-participation



Am 20.05.2015 um 14:17 schrieb Peter Kietzmann:

Hi everyone,

here is the link for the biweekly meeting:

http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- 



This is the first time that I started this conference, hope it works. 
For instructions of joining see:


http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc- 



Cheers,
Peter



--
Peter Kietzmann

Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49-40-42875-8426
Web: http://www.haw-hamburg.de/inet

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Biweekly virtual meeting

[Peter Kietzmann]

Hi everyone,

here is the link for the biweekly meeting:

http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-

This is the first time that I started this conference, hope it works. 
For instructions of joining see:


http://placecam.de/call.php?c=lmakKMrDG8a35aIBNqLBvOnApExkKFntj9xXawGNgTc-

Cheers,
Peter

--
Peter Kietzmann

Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49-40-42875-8426
Web: http://www.haw-hamburg.de/inet

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] IEEE802.15.4 discovery

[Jonas Remmert]

Hi,

Yes, that was the intention. However, I had some issues and didn´t 
really made huge progress. Will hopefully come to a clean solution for a 
csma_mac-layer that we need as a basis for further MAC layer. This will 
include message dispatching mechanisms, cca-mechanisms (backoff-time 
implementation when needed) and acknowledge handling (when needed).


As it seems, there are many people that would need an IEEE 802.15.4 
MAC-layer. Had also a discussion with Johann; we think an "IEEE 
802.15.4-MAC layer task force" might be a good idea. As a first step we 
could make a todo list, like [2] and a Wiki-page for further for further 
explanations.


What do you think of the idea of an "IEEE 802.15.4-MAC layer task 
force"? Maybe we can discuss that later in the bi-weekly meeting?


---
Some of my current considerations, for those who are interested.

# Message dispatching problem:
When a node will be associated to an PAN-coordinator, the transmitting 
and receiving time is guided on the superframe architecture. That means 
there will be timespans, where the node can not send messages. 
Nevertheless, there will be incoming task-messages from upper-layer to 
the MAC layer task.

1. Messages from upper layer  (Low-prio)
2. Messages from driver (isr-events)(High-prio)
3. Messages from timer(High-prio)
There must be a mechanism that (i) keeps the message queue empty. (ii) 
Takes care of the current MAC-layer state (just try to send a new packet 
when the MAC layer handled the previous one).


# Storing state variables for the MAC-layer state machine.
1. Static variables: Problem when we have more than one MAC-layer
2. Store them in the device-descriptor: The same device-descriptor may 
be used in different MAC-layer. How to choose the fitting variable set 
(at compile time)?

3. ?

# When these problems are solved, the discovering and associating 
mechanism will include the following tasks.


1. The handling of the incoming and outgoing packets has to be handled 
in the mac layer (currently this is done in each driver implementation). 
This should not be a big thing, as this is already prepared by hauke.


2. Some missing parts in ng_ieee802154. MAC layer settings that describe 
the device "capability information field" [1, section 5.3.1.2] 
(battery/stationary powered; Receiver on when Idle; security capability).


3. Introduce a new statemachine for current association state. The 
statemachine in the csma_mac-layer will be nested into this.


[1] - IEEE 802.15.4 Standard
[2] - https://github.com/RIOT-OS/RIOT/issues/2278

Best
Jonas


On 20.05.2015 10:28, Hauke Petersen wrote:

Hi,

@Jonas, is your 802.15.4 MAC layer implementation planned to cope with 
this?


Cheers,
Hauke


On 19.05.2015 20:18, Kaspar Schleiser wrote:

Hey,

is anybody working on or are there plans for support for discovering
802.15.4 PANs?

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] IEEE802.15.4 discovery

[Hauke Petersen]

Hi,

@Jonas, is your 802.15.4 MAC layer implementation planned to cope with this?

Cheers,
Hauke


On 19.05.2015 20:18, Kaspar Schleiser wrote:

Hey,

is anybody working on or are there plans for support for discovering
802.15.4 PANs?

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel