(my emphasis)

This is a major issue with GPRS for "unattended" applications!!
When there's a human operator to hand, they'll soon spot that there's a problem and try to reconnect; doing this programmatically is a lot more difficult.

As I mentioned before, there is no such thing as an incoming GPRS call; so if your remote device loses its connection, there's no way that the central server can contact it - it just has to wait & hope that the remote device will eventually call-in.

Therefore you will need to implement some sort of "keep-alive" or "heartbeat" protocol to keep testing that the link is still up, and to re-establish when it fails. This will inevitably lead to some extra traffic on the link; ie, some extra cost.
Because your payload sounds so small, it could well be swamped by this "housekeeping" stuff! :-(


Because GPRS is just an overlay on the existing GSM network, the amount of voice traffic may well affect the GPRS availability; if the network gets clogged with voice calls, there will be nothing left for GPRS! (we have seen this happen - possibly the network operator gives priority to voice calls?).


Actually, I was applying a general principle in a post about "normal" modems, but your're right; GPRS is far worse - you've got all the "normal" modem worries, plus the vagaries of a radio link plus an IP network!!
I you stopped to think about all the things that could possibly go wrong, you'd be amazed that it ever works at all!!


It is possible to set up a VPN (Virtual Private Network) over GPRS; however, whether your particular service provider has such an offering, and whether it's affordable for the application are entirely different matters...!
(I think this would usually only be offered to major corporate customers).


You get the same with SMS. :-(


Good point - although UDP doesn't give the guranteed reliable delivery of TCP, I think - so much like SMS, then... ;-)

You could also look at ICMP...