[riot-devel] Data Caching in GNRC, Vol 57, Issue 16

Häring Benjamin (haej) haej at zhaw.ch
Fri Nov 17 17:56:33 CET 2017


Hi Martine,

The second answer is exactly what I asked for.

> Regarding caching: no there is no possibility in GNRC to cache data for sleeping nodes at the moment.
Is such a solution planned for the GNRC? The stack would thus only be applicable to nodes with sufficient energy supply or not?

> Can you maybe describe your set-up further?
As mentioned, I stand at the beginning of my implementation. I wanted to ask before implementing my approaches if there are no other solutions in RIOT that I might have overlooked. I am currently concentrating even more on analyzing the behavior of the GNRC. For this, I use the two examples “gnrc_border_router” and “gnrc_networking” almost in their default state. I have just removed the RPL module because I am going for a star topology and not a mesh network.

> I'm particularly interested in how is the border router is notified that a node is going to sleep/is already sleeping?
My current approach is to assume that every node in the network is asleep. Therefore, every packet should end up in the cache until the node explicitly asks for data. Maybe a filter can be added, for caching only UDP packets for nodes. That could be done with the next header type in the IPv6 Header.
The request for pending data from the node could be solved doing a NUD from the node to the router at wakeup for example. In the same step, the problem might be solved with the long DELAY state phase (about 5 seconds). Because a NUD would be due anyway when sending the next IPv6 packet. 

Other possibility to request pending data is to send a MAC “DataRequest” Command to the router and check the “PendingData” flag in the ACK on MAC Layer.

An advantage of this two approaches are that awake phases are short in most cases and thus they could be done at shorter intervals without consuming much energy. 

Are these statements helpful in understanding my problem?

Regards,
Benjamin

-----Ursprüngliche Nachricht-----
Von: devel [mailto:devel-bounces at riot-os.org] Im Auftrag von devel-request at riot-os.org
Gesendet: Freitag, 17. November 2017 15:13
An: devel at riot-os.org
Betreff: devel Digest, Vol 57, Issue 16

Send devel mailing list submissions to
	devel at riot-os.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.riot-os.org/mailman/listinfo/devel
or, via email, send a message with subject or body 'help' to
	devel-request at riot-os.org

You can reach the person managing the list at
	devel-owner at riot-os.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of devel digest..."


Today's Topics:

   1. GNRC with sleepy nodes (Häring Benjamin (haej))
   2. Re: GNRC with sleepy nodes (Martine Lenders)
   3. Re: GNRC with sleepy nodes (Martine Lenders)


----------------------------------------------------------------------

Message: 1
Date: Fri, 17 Nov 2017 13:45:42 +0000
From: Häring Benjamin (haej) <haej at zhaw.ch>
To: "devel at riot-os.org" <devel at riot-os.org>
Subject: [riot-devel] GNRC with sleepy nodes
Message-ID: <a82d1fbe77b8489fa12196e9c445b662 at srv-mail-101.zhaw.ch>
Content-Type: text/plain; charset="iso-8859-1"

Hi all,

I have some questions about the possibilities of RIOT in the network area. First a short introduction about my work.
I am currently working on a project for a low power sensor network with an ATSAMR21G18A from Atmel and RIOT as operating system. The idea is to connect sleeping sensor nodes in a star topology with a border router in the middle. The sensor nodes should be IPv6 capable and provide a CoAP server. Next, the node should also spend some time in the sleeping state. The resulting latencies are deliberately accepted.

I have already done some experiments with the "gnrc_border_router" and "gnrc_networking" examples. There was a question about Neighbor Discovering. Some of the time constants (e.g., DELAY_FIRST_PROBE_TIME) are inherited from RFC4861, but others have been adjusted (e.g., REACHABLE_TIME of 18s). Is there a rationale for choosing these values?

At the moment it looks like I am develop my own border router base on the "gnrc_border_router" example and trying to cache the data traffic for sleeping sensor nodes until they wake up and ask for the data (like the Thread Stack does). I would be interested if my approach is correct.

Is there also a possibility with GNRC stack that I overlooked? Or examples of this approach?

Best regards
Benjamin Häring
---------------------------------------------------
ZHAW School of Engineering
Benjamin Häring, BSc ZFH in Electrical Engineering Wissenschaftlicher Assistent

InES, Institute of Embedded Systems
Technikumstrasse 22
Postfach
8401 Winterthur

Telefon +41 58 934 71 48
benjamin.haering at zhaw.ch<mailto:benjamin.haering at zhaw.ch>
www.ines.zhaw.ch<http://www.ines.zhaw.ch/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20171117/8586bb0a/attachment-0001.html>

------------------------------

Message: 2
Date: Fri, 17 Nov 2017 15:03:16 +0100
From: Martine Lenders <mail at martine-lenders.eu>
To: RIOT OS kernel developers <devel at riot-os.org>
Subject: Re: [riot-devel] GNRC with sleepy nodes
Message-ID:
	<CALHmdRw+GkwBRU2fSvp=Z09Je3rvOdrx9r-WhEP+dYth2mwc3g at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,

since the timers you mentioned are dependent on xtimer and since xtimer has some known issues with power management (what those are directly I can't say due to my own lack of knowledge there, some hardware person on this list might give you more detailed information on that) in the default configuration, sleeping is not currently possible with GNRC on ATSAMR21G18A-based platforms (at least, as I understand it in the default configuration).

Cheers,
Martine

2017-11-17 14:45 GMT+01:00 Häring Benjamin (haej) <haej at zhaw.ch>:

> Hi all,
>
>
>
> I have some questions about the possibilities of RIOT in the network area.
> First a short introduction about my work.
>
> I am currently working on a project for a low power sensor network 
> with an ATSAMR21G18A from Atmel and RIOT as operating system. The idea 
> is to connect sleeping sensor nodes in a star topology with a border 
> router in the middle. The sensor nodes should be IPv6 capable and 
> provide a CoAP server. Next, the node should also spend some time in the sleeping state.
> The resulting latencies are deliberately accepted.
>
>
>
> I have already done some experiments with the "gnrc_border_router" and 
> "gnrc_networking" examples. There was a question about Neighbor 
> Discovering. Some of the time constants (e.g., DELAY_FIRST_PROBE_TIME) 
> are inherited from RFC4861, but others have been adjusted (e.g., 
> REACHABLE_TIME of 18s). Is there a rationale for choosing these values?
>
>
>
> At the moment it looks like I am develop my own border router base on 
> the “gnrc_border_router” example and trying to cache the data traffic 
> for sleeping sensor nodes until they wake up and ask for the data 
> (like the Thread Stack does). I would be interested if my approach is correct.
>
>
>
> Is there also a possibility with GNRC stack that I overlooked? Or 
> examples of this approach?
>
>
>
> Best regards
>
> Benjamin Häring
>
> –––––––––––––––––––––––––––––––––––––––––––––––––––
>
> ZHAW School of Engineering
>
> Benjamin Häring, BSc ZFH in Electrical Engineering
>
> Wissenschaftlicher Assistent
>
>
>
> InES, Institute of Embedded Systems
>
> Technikumstrasse 22
>
> Postfach
>
> 8401 Winterthur
>
>
>
> Telefon +41 58 934 71 48 <+41%2058%20934%2071%2048>
>
> benjamin.haering at zhaw.ch
>
> www.ines.zhaw.ch
>
>
>
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20171117/abe10c46/attachment-0001.html>

------------------------------

Message: 3
Date: Fri, 17 Nov 2017 15:12:58 +0100
From: Martine Lenders <mail at martine-lenders.eu>
To: RIOT OS kernel developers <devel at riot-os.org>
Subject: Re: [riot-devel] GNRC with sleepy nodes
Message-ID:
	<CALHmdRx=rtFveT8x0foziw0oLRm=sDptmDjMBu+DBkhP0LOEcQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi again,

After re-reading your mail, I think I misunderstood your question...

Regarding caching: no there is no possibility in GNRC to cache data for sleeping nodes at the moment. Can you maybe describe your set-up further?
I'm particularly interested in how is the border router is notified that a node is going to sleep/is already sleeping?

Cheers,
Martine

2017-11-17 15:03 GMT+01:00 Martine Lenders <mail at martine-lenders.eu>:

> Hi,
>
> since the timers you mentioned are dependent on xtimer and since 
> xtimer has some known issues with power management (what those are 
> directly I can't say due to my own lack of knowledge there, some 
> hardware person on this list might give you more detailed information 
> on that) in the default configuration, sleeping is not currently 
> possible with GNRC on ATSAMR21G18A-based platforms (at least, as I understand it in the default configuration).
>
> Cheers,
> Martine
>
> 2017-11-17 14:45 GMT+01:00 Häring Benjamin (haej) <haej at zhaw.ch>:
>
>> Hi all,
>>
>>
>>
>> I have some questions about the possibilities of RIOT in the network 
>> area. First a short introduction about my work.
>>
>> I am currently working on a project for a low power sensor network 
>> with an ATSAMR21G18A from Atmel and RIOT as operating system. The 
>> idea is to connect sleeping sensor nodes in a star topology with a 
>> border router in the middle. The sensor nodes should be IPv6 capable 
>> and provide a CoAP server. Next, the node should also spend some time in the sleeping state.
>> The resulting latencies are deliberately accepted.
>>
>>
>>
>> I have already done some experiments with the "gnrc_border_router" 
>> and "gnrc_networking" examples. There was a question about Neighbor 
>> Discovering. Some of the time constants (e.g., 
>> DELAY_FIRST_PROBE_TIME) are inherited from RFC4861, but others have 
>> been adjusted (e.g., REACHABLE_TIME of 18s). Is there a rationale for choosing these values?
>>
>>
>>
>> At the moment it looks like I am develop my own border router base on 
>> the “gnrc_border_router” example and trying to cache the data traffic 
>> for sleeping sensor nodes until they wake up and ask for the data 
>> (like the Thread Stack does). I would be interested if my approach is correct.
>>
>>
>>
>> Is there also a possibility with GNRC stack that I overlooked? Or 
>> examples of this approach?
>>
>>
>>
>> Best regards
>>
>> Benjamin Häring
>>
>> –––––––––––––––––––––––––––––––––––––––––––––––––––
>>
>> ZHAW School of Engineering
>>
>> Benjamin Häring, BSc ZFH in Electrical Engineering
>>
>> Wissenschaftlicher Assistent
>>
>>
>>
>> InES, Institute of Embedded Systems
>>
>> Technikumstrasse 22
>>
>> Postfach
>>
>> 8401 Winterthur
>>
>>
>>
>> Telefon +41 58 934 71 48 <+41%2058%20934%2071%2048>
>>
>> benjamin.haering at zhaw.ch
>>
>> www.ines.zhaw.ch
>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20171117/9fb0baf1/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
devel mailing list
devel at riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


------------------------------

End of devel Digest, Vol 57, Issue 16
*************************************


More information about the devel mailing list