Hi Sylvain,
On Wed, Dec 23, 2009 at 02:30:34AM +0100, Sylvain Munaut wrote:
The main.c is currently a test stub, reading from a file, printing on stdout, but fixing that into something usable for 26c3 shouldn't be long. I'm working on SMS and ciphering right now but at worse I could write something up in the plane or the day just before.
Don't bother with encryption (at least not for the 26C3)...
The plan was to have a daemon running that would essentially play the role of the LCS, mapping a tcp session to a RRLP session. This way I could have re-used the same code for both openbsc/openbts.
Mh, that would be possible, too. I thought reading from a file is even simpler, but handing all data off to a TCP socket is certainly also not much more difficult.
The biggest task is the APDU fragmentation/reassembly that needs to be done. At the moment I have no idea how flow control would be implemented for this, as we have a very fat TCP pipe to the LCS but a very narrow SDCCH on the other end. And the narrow pipe terminates at the BTS, while the TCP socket terminates at the BSC. We have no clue when the BTS's per-channel buffers will overrun, all we might get is a generic indication that the A-bis interface is overloaded (and that's too late).
How big is the ephemeris data from your experience?
It also misses the Reference Position decoding/encoding (currently my home GPS coordinates are hardcoded :), I'll have to fix that.
That's quick to fix.
BTW, when do you setup the network ? I should be in Berlin the 26th late afternoon if you need help setup/pre-testing.
We'll set it up in the 25th and 26th morning, so by late afternoon everything should already be running (though the license only allows us to switch it on on the 27th).