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
Hi again,
this is an incremental update to the one released two days ago.
I've now just established the first couple of HTTP connections from a Android G1 phone through a self-hosted combination of nanoBTS, OpenBSC, OsmoSGSN and OpenGGSN.
The setup is still very flaky and I'm hunting down some crashes of OsmoSGSN, we also still take shortcuts everywhere in the spec and e.g. only implement SNDCP fragmentation on the downlink and no fragment re-assembly on the uplink. But we're slowly getting there.
I hope this work will be completed and stabilize through the next couple of weeks.
Also, the performance is probably really bad, there are many linear list searches and lookups at the inter-layer transitions of the GPRS protocol stack. But I have lots of ideas how to simplify this by introducing direct pointer references (as opposed to lookup-by-identifier) between the various state structures of each respective layer.
Regards, Harald
Hi,
I tried the gprs yesterday, and in the end, it worked quite well albeit slow (but that's GPRS I guess :p)
I had to fix a couple of crashes (both of SGSN and of the BTS, the latter being due to malformed packets) and the fixes are in my sylvain/pending branch.
Also, a couple of 'gotcha' I hit for future reference: - Even if running on the same machine, the SGSN & GGSN GTP interfaces need to have different IPs or they'll try to bind to the same ports and fail. - Using 'TCH/F_PDCH' channel config doesn't work (that's what I used with the old gprs branch a long time ago). You need to use 'PDCH'
Finally a list of the IPs in the configuration and what they mean (I stumbled a little when trying to setup all those :):
----- In openbsc.cfg:
gprs nsvc 0 local udp port 23000 gprs nsvc 0 remote udp port 23000 gprs nsvc 0 remote ip A.B.C.D
A.B.C.D -> This is the IPs of the SGSN that will be sent to the BTS (and the BTS will try to connect to it obviously ...)
In osmo_sgsn.cfg: gtp local-ip A.B.C.D ggsn 0 remote-ip W.X.Y.Z
A.B.C.D -> This is the local ip of the SGSN where the GTP link (between GGSN & SGSN) will be bound to. W.X.Y.Z -> This is the ip of the GGSN for the GTP link.
As I mentionned earlier, even if both SGSN & GGSN are running on the same machine, they need to be different (using ip aliases or whatever)
encapsulation udp local-ip A.B.C.D encapsulation udp local-port 23000
A.B.C.D -> This is the ip/port the BTS will connect to. Must obviously match the 'gprs nsvc 0 remote' config in openbsc.cfg
In ggsn.conf:
listen A.B.C.D
A.B.C.D -> This is the local IP for the GTP link of the GGSN. Must match the 'ggsn 0 remote-ip' of osmo_sgsn.cfg -----
Sylvain
Hi Sylvain,
thanks for reproducing the GPRS setup, it is always useful to know it works for other people, too.
On Thu, Jun 10, 2010 at 09:47:08AM +0200, Sylvain Munaut wrote:
I tried the gprs yesterday, and in the end, it worked quite well albeit slow (but that's GPRS I guess :p)
You can cofigure multiple timeslots as PDCH. It will work transparently as the load distribution is done by the BTS alone.
I'm happy (though surprised) it worked for you fine. The biggest problems at the moment are * no defragmentation of fragmented SNDCP PDU's in the MS->network direction * lack of BSSGP flow control (implementing it right now)
I had to fix a couple of crashes (both of SGSN and of the BTS, the latter being due to malformed packets) and the fixes are in my sylvain/pending branch.
I'm happy to look at them.
Also, a couple of 'gotcha' I hit for future reference:
- Even if running on the same machine, the SGSN & GGSN GTP interfaces
need to have different IPs or they'll try to bind to the same ports and fail.
Yes, that is almost expected. We could add config options to bind to non-standard ports to fix this - but at the cost of having to manually click 'decode as...' every time in wireshark.
- Using 'TCH/F_PDCH' channel config doesn't work (that's what I used
with the old gprs branch a long time ago). You need to use 'PDCH'
This is true and known. a TCH/F_PDCH combination will need an explicit ip.access proprietary RSL "PDCH ACTIVATE" message, and although I have written some code for dynamic PDCH/TCH_F allocation in OpenBSC, this has never been tested (and i believe it's out of the master branch).
Finally a list of the IPs in the configuration and what they mean (I stumbled a little when trying to setup all those :):
It would be great if you could work on an article on the wiki how to set this up. The configuration/vty commands should be stable and I don't expect this to change anymore.
Hi,
I'm happy (though surprised) it worked for you fine.
Yup I was too to see that now it actually _worked_. Last time I tried it was still the separate gprs branch.
A quick speed test gives a breathtaking 4.3 ko/s :)
Here are a few weird message I still get from time to time on the nanoBTS telnet interface:
--- 13113:DBG:RM:dlTbfUtilsTerminateExtendedUlTbf() 9:DBG:RM:dlTbfUtilsTerminateExtendedUlTbf() ---
And some on sgsn process as well (no relation with the telnet ones):
--- <0016> gprs_bssgp.c:349 BSSGP TLLI=0xcedb4983 Rx UL-UD missing mandatory IE <0016> gprs_bssgp_util.c:105 BSSGP BVCI=0 Tx STATUS, cause=Missing mandatory IE ---
It would be great if you could work on an article on the wiki how to set this up. The configuration/vty commands should be stable and I don't expect this to change anymore.
Ok, done at http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS
Cheers, Sylvain
Hi Sylvain,
On Fri, Jun 11, 2010 at 12:54:36AM +0200, Sylvain Munaut wrote:
Here are a few weird message I still get from time to time on the nanoBTS telnet interface:
13113:DBG:RM:dlTbfUtilsTerminateExtendedUlTbf() 9:DBG:RM:dlTbfUtilsTerminateExtendedUlTbf()
This definitely relates to TBF (temporary block flow), a concept on the air interface. So I'm not quite sure how the Gb interface (SGSN side) would have any direct contact with TBF's.
And some on sgsn process as well (no relation with the telnet ones):
<0016> gprs_bssgp.c:349 BSSGP TLLI=0xcedb4983 Rx UL-UD missing mandatory IE <0016> gprs_bssgp_util.c:105 BSSGP BVCI=0 Tx STATUS, cause=Missing mandatory IE
Ok, we should probably print which IE we think is missing, or even better, we should add some functionality that can put such supposedly-erroneous packets in a pcap file. Once we have a simple function that can be called for this, we can use it all over the code.
Ok, done at http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS
Thanks.
-
Harald Welte -
Holger Hans Peter Freyther -
Sylvain Munaut