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:[email protected]] Im Auftrag von [email protected] Gesendet: Freitag, 17. November 2017 15:13 An: [email protected] Betreff: devel Digest, Vol 57, Issue 16 Send devel mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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) <[email protected]> To: "[email protected]" <[email protected]> Subject: [riot-devel] GNRC with sleepy nodes Message-ID: <[email protected]> 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 [email protected]<mailto:[email protected]> 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 <[email protected]> To: RIOT OS kernel developers <[email protected]> Subject: Re: [riot-devel] GNRC with sleepy nodes Message-ID: <CALHmdRw+GkwBRU2fSvp=z09je3rvodrx9r-whep+dyth2mw...@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) <[email protected]>: > 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> > > [email protected] > > www.ines.zhaw.ch > > > > _______________________________________________ > devel mailing list > [email protected] > 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 <[email protected]> To: RIOT OS kernel developers <[email protected]> Subject: Re: [riot-devel] GNRC with sleepy nodes Message-ID: <CALHmdRx=rtFveT8x0foziw0oLRm=sdptmdjmbu+dbkhp0lo...@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 <[email protected]>: > 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) <[email protected]>: > >> 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> >> >> [email protected] >> >> www.ines.zhaw.ch >> >> >> >> _______________________________________________ >> devel mailing list >> [email protected] >> 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 [email protected] https://lists.riot-os.org/mailman/listinfo/devel ------------------------------ End of devel Digest, Vol 57, Issue 16 ************************************* _______________________________________________ devel mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/devel
