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).
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)