That’s mainly a question for your network provider and about your network setup.
In many cases, the device sends IP messages through the network provider’s “internet breakout” which uses a NAT. If that is also your case, your IP message from your server will not be forwarded to the device after a quiet period.
Some provider offer also to use a ip-tunnel and static private ip-addresses when using that tunnel. That reduces then the task to define, “how frequently” your device turns on the receiver. With PSM something as 1 hour may work, with eDRX also shorter periods work (with a higher energy consumption).
Finally you need to check the ip-configuration of your server. Sometimes the server side use also a “incoming” based function and doesn’t support “outgoing” well.
Depending on the “receiver interval”, you may also consider to use a device initiated “alive-message”. That helps a lot to also detect system failures. And makes it easy to send a cmd message back. It comes with extra data and extra energy costs, so I guess you need to check, if that works for your case as well. In my experience, if a “alive interval of 1h” does it, the costs seems to be affordable (using CoAP/DTLS 1.2 CID/UDP) and works “out-of-the-box” in many network environments. In practice my data volume for 3 months every hour, static location, was about 2 MByte and it consumed about 400mAh with a Thingy:91. I usually send sensor values as “alive message”. A feather should do it with less energy (lower quiescent current), but for now I had not the time for a test run with a feather v5.
