> 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