It's the year **2024**, so that's 2.024K (or G for *grand*), right?
What does it mean to use 2.024 G data (aka EDGE 2.5G) in the year 2024?
Our Osmocom 2G Data stack seems pretty mature at this point.
Within the limits of the technology one can still use a remote ssh session, download email, do "instant messaging", including sending photos and short audio messages.
All this works fine with one or two UE connected on a lab desk to a TRX configured for *high* capacity,
However, introduce some TCH "stealing" the PDCH, some several 100's of UE (even just trying to attach) and some non optimal RF conditions and the capacity of the TRX is severely reduced.
In these conditions, modern Android phones will saturate the TRX' capacity even with only their DNS lookups for "connectivity.google.com" - Maybe somewhat ironically?
I've considered various steps to try to mitigate this situation.
A common goto is to interfere with DNS, but this is disastrous.
* In some cases, if Android cannot reach 8.8.8.8, regardless of what the network said to use for DNS, it will simply try again. - Of course, that can't be right. right?
* If connectivity.google.com doesn't resolve, well that can't be right either, so try again.
* If connectivity.google.com resolves, then HTTP GET /generate_204, and if this doesn't work, report to upper layer that there is no "Internet" and... you guessed it, try again.
So we have to allow these things, which in itself is OK, as once the 204 is received, the phone will (probably) leave that alone, at least for a few minutes, but what comes next is all of what one might imagine is in the various phones, checks for system updates, app stores updates, uploading all the surveillance info that the google "services" cached while disconnected, and *who knows what else.
*those running HTTP toolkit ;-)
And that's before we even consider whatever is installed in "user space" (if such a thing can really be considered to exist on an Android device) starts.
My current solution to this is to allow a limited amount of services, and then use netfilter's TARPIT module to get the phones to back off from everything else.
Let's look a little a that, and maybe discuss what other optimizations could be done - For example netfilter scheduling and queues at the GGSN's IP interface. How about limiting the DL bandwidth per IP at this point? Give ACKs and short packets priority? We could limit the bandwidth here to the TRX capacity, but what if there is more than one SGSN, maybe an unknown number of SGSN (and TRX) connected at any one time?
Now I've pretty much said everything I had to say in this description! But if would be good to discuss it, you all probably have some ideas!