RRLP / ephemeris data

[Harald Welte]

Dear Daniel and Jan,

you have been working very closely with and on the u-blox GPS receiver
during your work on the Openmoko GTA02.

As far as I know, it is possible to obtain the ephemeris data from a u-blox
receiver.

I would like to see some code that obtains and converts that ephemeris data
into the format described by the RRLP protocol specification. I know this
involves asn.1 PER ugliness, but this can all be done well outside the OpenBSC
codebase.

What I'll propose is to simply use some pattern matching to determine the RRLP
request for assistance data, and if such a request exists, open some file in
the filesystem and send the contents binary as-is to the phone in response.

Any responses from the phone are already stored in the database anyway.

In case any of you are interested in working on something to generate the
required ephemeris data and have time before or even at the 26C3, you can
simply give me the resulting binary file, I can drop it into the OpenBSC
directory and we'll see what happens.

If this doesn't happen right now, it doesn't matter all that much, as the 26C3
is an indoor event and I don't think we'll be getting that many GPS fixes
in such an environment anyway. But eventually, for the next outdoor test,
and to do some more RRLP security research, the ephemeris data formatter
would be really great!

Cheers,
Harald

[Sylvain Munaut]

Just FYI, I have code that generates the ephemeris data in the good format
for RRLP message from a u-blox receiver.
I sent it to dieter, just need to plug it into openbsc.

Post by Harald Welte
Dear Daniel and Jan,
you have been working very closely with and on the u-blox GPS receiver
during your work on the Openmoko GTA02.
As far as I know, it is possible to obtain the ephemeris data from a u-blox
receiver.
I would like to see some code that obtains and converts that ephemeris data
into the format described by the RRLP protocol specification. I know this
involves asn.1 PER ugliness, but this can all be done well outside the OpenBSC
codebase.
What I'll propose is to simply use some pattern matching to determine the RRLP
request for assistance data, and if such a request exists, open some file in
the filesystem and send the contents binary as-is to the phone in response.
Any responses from the phone are already stored in the database anyway.
In case any of you are interested in working on something to generate the
required ephemeris data and have time before or even at the 26C3, you can
simply give me the resulting binary file, I can drop it into the OpenBSC
directory and we'll see what happens.
If this doesn't happen right now, it doesn't matter all that much, as the 26C3
is an indoor event and I don't think we'll be getting that many GPS fixes
in such an environment anyway. But eventually, for the next outdoor test,
and to do some more RRLP security research, the ephemeris data formatter
would be really great!
Cheers,
Harald
--
- 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)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20091222/4db3167d/attachment.html>

[Sylvain Munaut]

Damn, I forgot the link :

http://www.246tnt.com/files/rrlp-20091101.tar.bz2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20091222/4dd23cf3/attachment.html>

[Harald Welte]

Post by Sylvain Munaut
Just FYI, I have code that generates the ephemeris data in the good format
for RRLP message from a u-blox receiver.
I sent it to dieter, just need to plug it into openbsc.

That's great!

I remember hearing/reading that you've been working on it, but never
realised that this work was actually completed. Thanks a lot.

I've imported it into the openbsc.git repository, hope you don't mind.

[Sylvain Munaut]

Post by Harald Welte

Post by Sylvain Munaut
Just FYI, I have code that generates the ephemeris data in the good

format

Post by Sylvain Munaut
for RRLP message from a u-blox receiver.
I sent it to dieter, just need to plug it into openbsc.

That's great!
I remember hearing/reading that you've been working on it, but never
realised that this work was actually completed. Thanks a lot.

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.

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.

It also misses the Reference Position decoding/encoding (currently my home
GPS coordinates are hardcoded :), I'll have to fix that.

BTW, when do you setup the network ? I should be in Berlin the 26th late
afternoon if you need help setup/pre-testing.

Post by Harald Welte
I've imported it into the openbsc.git repository, hope you don't mind.

Not at all, that's what it was written for :)


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

[Harald Welte]

This post might be inappropriate. Click to display it.

[Sylvain Munaut]

Post by Harald Welte

Post by Sylvain Munaut
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.

Post by Harald Welte
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.

Post by Harald Welte
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.html>

[Dieter Spaar]

Hello Sylvain,

I finally found the time to play with the RRLP encoding of
the GPS assistance data, sorry for the long delay.

When comparing the encoded PDUs with the data from an evaluation
version of a commercial ASN1 too, I found several problems which seem
to come from a bug in the ASN1 unaligned PER encoder of ASN1C. I can
also confirm this problem by simply trying to decode the generated PDUs
with the ASN1 decoder from ASN1C, it shows the same error as the
commercial tool.

I think I have found the bug and a fix for it, however I have not
yet confirmed that it really works with a phone, I currently just check
the PDUs. I will try to test it with a phone, if anyone is currently
playing with RRLP, I can of course send the bug fix (I am just not yet
100% sure with it).

Just in case, I use ASN1C from the SourceForge subversion repository.

Best regards,
Dieter

[Sylvain Munaut]

Hi,

I think I have found the bug and a fix for it, however I have not

Post by Dieter Spaar
yet confirmed that it really works with a phone, I currently just check
the PDUs. I will try to test it with a phone, if anyone is currently
playing with RRLP, I can of course send the bug fix (I am just not yet
100% sure with it).

Yes, I'd definitly be interested in that bug fix :)

Post by Dieter Spaar
Just in case, I use ASN1C from the SourceForge subversion repository.

me as well.


Cheers,

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20091227/74b10b66/attachment.html>