RRLP / ephemeris data
laforge at gnumonks.org
Wed Dec 23 10:36:28 CET 2009
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
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
More information about the OpenBSC