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?