GPRS EXperiments

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Neels Hofmeyr nhofmeyr at sysmocom.de
Fri Nov 3 17:59:00 UTC 2017


(BTW, for GPRS we use osmocom-net-gprs at lists.osmocom.org but admittedly, almost
all osmocom communication is taking place on openbsc@)

On Mon, Oct 30, 2017 at 12:12:03PM -0600, Keith wrote:
> I've installed up to date versions of osmo-bts and osmo-pcu
> on sysmobts 2050 hardware and it's working great!
> Dynamic channels are really nice, with half rate TCH and AMR
> working perfectly. Thanks for all that work!

Good to hear that!

> I configured pcodns1 in the ggsn to point to this DNS
> server, AND I setup a port 53 redirect to catch quite a lot
> of traffic from android that likes to just talk directly to
> 8.8.8.8 anyway.

Interesting, this sounds like it would make for a good wiki page on
osmocom.org.

> games. Such is the sad state of affairs on today's internet.
> Fortunately, we have iptables and ip sets and we have AS
> blocks assigned to certain bandwidth hungry corporations :-)

So instead of compromising net neutrality by giving the rich more bandwidth,
you do it by cutting the big ones out instead ;)

> I have observed that if I initiate any data transfer from
> the network side then the uplink is established. By the same
> token, If I transfer a file from the network (http download
> or some such), the same applies. The link stays active and
> the IM chat session is very responsive alongside the file
> transfer. Shortly after the file transfer completes, the
> uplink is quiet again and the latency in the IM session
> becomes a problem.

It might be related to a basic problem we still have with data services: we
don't cache anything. If a PDP context is still being established, we drop data
transfers to the floor, instead of storing them and sending them through when
the context is established. I'm personally not familiar with the details there,
but that's my current understanding.

So a first ping would get lost, a second one within a timeframe that still has
the PDP context open will go through.

I think the idea there is that generally, higher level data communication
should attempt to resend, but in practice that often doesn't seem to work that
well.

Not sure how to configure the PDP context timeout, or whether we even can.

Theoretically, if you had on your phone a regular ping running in the
background ... it's ugly, but yea.

Caching those first packets is quite complex, especially for SGSNs sitting on a
small device like a sysmoBTS with limited memory. I guess something could be
tried there, by limiting resources used for caching in intelligent ways...

Someone would need to fund that, or go ahead and try.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171103/3f6317a2/attachment.bin>


More information about the OpenBSC mailing list