GPRS/SGSN progress update

historical

Hi all,

I've been working on the SGSN code again for two days, and there is quite
a bit of progress, even if it doesn't really make much difference in
what you can do.

I'm still working on the signalling plane, an we still cannot send/receive
user plane packets (the actual TCP/IP).

However, a number of bugs / misunderstandings have been fixed:

1) When we send BSSGP Downlink-Unitdata, we have to always include the IMSI
   of the target phone, as well as the "MS Radio Access Capabilities" IE.
   This is apparently needed for the BTS to know when and how it can schedule
   packets to be sent on the radio interface.  However, I personally think
   it's an ugly layering violation.  All this information is part of the
   "GMM State" in the SGSN, i.e. higher than layer3.  It now needs to be
   passed through LLC down into BSSGP, where it is used :(

2) LLC UI Frames have sequence numbers that need to be incremented with
   every frame.

3) Some phones apparently don't like it if they don't get a P-TMSI allocated
   during GPRS ATTACH and ROUTEING AREA UPDATE.  According to the spec,
   it's optional and I thought I could skip that feature to make things
   easier initially.

4) There are two levels of C/R (Command/Response) bits, one at the LLC and
   the other at the BSSGP layer.  The LLC bit is now set correctly, but the
   BSSGP C/R packet seems to be set even wrong by the BTS.  However, I'm
   now simulating the behaviour of exissting Gb protocol traces

5) The 04.08 GMM timers T3350 and T3370 have been implemented properly,
   including re-transmissions of the according MM frames

6) As part of P-TMSI Reallocation, there are time windows when the SGSN
   has to consider both the old and the newly allocated P-TMSI are valid
   simultaneously

Finally, I've found one other bug that I'm about to fix now:  When we assign a
new P-TMSI, this implicitly means that the TLLI will change, too.  Since the
TLLI changes, the LLC protocol created a new "LL Entity" data structure and
re-started the sequence number at 0, resulting in all messages being dropped
in the phone until the sequence number is higher than the previous one.

I have some hope that this is the last bug before I can see packets on the data
plane coming out the TUN device on OpenGGSN.

After that, there are still the following major TODOs:
* actually check the HLR rather than accepting every IMSI
* implement BSSGP flow control for BVC and MS level
* implement SNDCP fragmentation/reassembly

Followed by more optional features, such as
* implement SNDCP header compression
* implement SNDCP payload compression
* implement LLC re-transmissions
* implement GEA3 encryption

Regards,
	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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20100601/29cc8eb9/attachment.bin>