RRLP / ephemeris data

historical

> > 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)...
>

I know it's not much use for events since you need a known Ki which most
people don't have that.
But looking at it yesterday, it seemed pretty straightforward to
implement and if the user doesn't have a Ki in the HLR, that code path would
not be executed at all ...
Basically for :
 - LOCATION UPDATE REQUEST
 - PAGING RESPONSE
 - CM SERVICE REQUEST

You need :
 - Test if key_seq is the last known key_seq,
 - If yes you can just re-use the last Kc and send cipher mode command
 - If no, need to do an auth request, then send cipher mode command
 - On cipher mode complete, just pursue the task you were asked to do (loc
update or paging. for cm service ack, the cipher mode command means implicit
ack).

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).
>

Application PDU do have a fragmentation mechanism but you can't use it. The
spec says :

"""
The RRLP maximum PDU size is 242 octets. If the amount of data that needs to
be sent is larger than RRLP maximum
PDU size, the RRLP pseudo-segmentation shall be used. The RRLP
pseudo-segmentation is the use of several RRLP
components (one in each RRLP message) to deliver a large amount of
information. For SMLC to MS messages, the
Assistance Data component is the one that is sent several times in order to
deliver the information. For MS to SMLC
messages, the Measure Position Response component may be sent twice in order
to deliver the information. Legacy MS
and SMLC (3GPP Rel-4 or older) may send RRLP components that are larger than
the RRLP maximum PDU size. In
this case lower level segmentation will be used.
"""

However, in my experience, low level segmentation (as described in gsm 04.08
3.4.21.2.2) just isn't accepted by the handsets I have.
So we have to use pseudo segmentation where we send multiple complete RRLP
messages.

> How big is the ephemeris data from your experience?
>

Around 12 APDU of 200 bytes in average. (for ref location + ref time + full
almanach + ephemeris for 12 SVs).

    Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20091223/6e458008/attachment.htm>