<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> The main.c is currently a test stub, reading from a file, printing on<br>
> stdout, but fixing that into something usable for 26c3 shouldn't be long.<br>
> I'm working on SMS and ciphering right now but at worse I could write<br>
> something up in the plane or the day just before.<br>
><br>
<br>
</div>Don't bother with encryption (at least not for the 26C3)...<br></blockquote><div><br>I know it's not much use for events since you need a known Ki which most people don't have that.<br>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 ...<br>
Basically for :<br> - LOCATION UPDATE REQUEST<br> - PAGING RESPONSE<br> - CM SERVICE REQUEST<br><br>You need :<br> - Test if key_seq is the last known key_seq,<br> - If yes you can just re-use the last Kc and send cipher mode command<br>
 - If no, need to do an auth request, then send cipher mode command<br> - 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). <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The biggest task is the APDU fragmentation/reassembly that needs to be done.<br>
At the moment I have no idea how flow control would be implemented for this,<br>
as we have a very fat TCP pipe to the LCS but a very narrow SDCCH on the other<br>
end.   And the narrow pipe terminates at the BTS, while the TCP socket<br>
terminates at the BSC.  We have no clue when the BTS's per-channel buffers<br>
will overrun, all we might get is a generic indication that the A-bis interface<br>
is overloaded (and that's too late).<br></blockquote><div><br>Application PDU do have a fragmentation mechanism but you can't use it. The spec says :<br><br>"""<br>The RRLP maximum PDU size is 242 octets. If the amount of data that needs to be sent is larger than RRLP maximum<br>
PDU size, the RRLP pseudo-segmentation shall be used. The RRLP pseudo-segmentation is the use of several RRLP<br>components (one in each RRLP message) to deliver a large amount of information. For SMLC to MS messages, the<br>
Assistance Data component is the one that is sent several times in order to deliver the information. For MS to SMLC<br>messages, the Measure Position Response component may be sent twice in order to deliver the information. Legacy MS<br>
and SMLC (3GPP Rel-4 or older) may send RRLP components that are larger than the RRLP maximum PDU size. In<br>this case lower level segmentation will be used.<br>"""<br><br>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.<br>
So we have to use pseudo segmentation where we send multiple complete RRLP messages.<br><br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

How big is the ephemeris data from your experience?<br></blockquote><div> <br>Around 12 APDU of 200 bytes in average. (for ref location + ref time + full almanach + ephemeris for 12 SVs).<br><br><br>    Sylvain<br><br></div>
</div>