Hi Sylvain,
thanks for reproducing the GPRS setup, it is always useful to know it works for other people, too.
On Thu, Jun 10, 2010 at 09:47:08AM +0200, Sylvain Munaut wrote:
I tried the gprs yesterday, and in the end, it worked quite well albeit slow (but that's GPRS I guess :p)
You can cofigure multiple timeslots as PDCH. It will work transparently as the load distribution is done by the BTS alone.
I'm happy (though surprised) it worked for you fine. The biggest problems at the moment are * no defragmentation of fragmented SNDCP PDU's in the MS->network direction * lack of BSSGP flow control (implementing it right now)
I had to fix a couple of crashes (both of SGSN and of the BTS, the latter being due to malformed packets) and the fixes are in my sylvain/pending branch.
I'm happy to look at them.
Also, a couple of 'gotcha' I hit for future reference:
- Even if running on the same machine, the SGSN & GGSN GTP interfaces
need to have different IPs or they'll try to bind to the same ports and fail.
Yes, that is almost expected. We could add config options to bind to non-standard ports to fix this - but at the cost of having to manually click 'decode as...' every time in wireshark.
- Using 'TCH/F_PDCH' channel config doesn't work (that's what I used
with the old gprs branch a long time ago). You need to use 'PDCH'
This is true and known. a TCH/F_PDCH combination will need an explicit ip.access proprietary RSL "PDCH ACTIVATE" message, and although I have written some code for dynamic PDCH/TCH_F allocation in OpenBSC, this has never been tested (and i believe it's out of the master branch).
Finally a list of the IPs in the configuration and what they mean (I stumbled a little when trying to setup all those :):
It would be great if you could work on an article on the wiki how to set this up. The configuration/vty commands should be stable and I don't expect this to change anymore.