Hello,
I use OpenBSC/GPRS (sw version only few weeks old) with nanoBTS and this works well mith many mobile devices. With Nokia devices, however, I do not get a PDP context. Here is an osmo-sgsn trace of Nokia E65:
<0012> gprs_bssgp.c:347 BSSGP TLLI=0x795b37eb Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0xc2ab0aCMD=UI DATA <0013> gprs_llc.c:742 LLC RX: unknown TLLI 0x795b37eb, creating LLME on the fly <0002> gprs_gmm.c:636 -> GMM ATTACH REQUEST MI(001011474110317) type="GPRS attach" <0002> gprs_gmm.c:351 <- GPRS ATTACH ACCEPT (new P-TMSI=0x78bb36bb) <0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS <0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS <0012> gprs_bssgp.c:347 BSSGP TLLI=0xf8bb36bb Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0xc2ab0aCMD=UI DATA //remark: is a repetition of GMM ATTACH REQUEST <0013> gprs_llc.c:525 TLLI=f8bb36bb dropping UI, N(U=0) not in window V(URV(UR:1). <0012> gprs_bssgp.c:347 BSSGP TLLI=0xf8bb36bb Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x478a8dCMD=UI DATA <0002> gprs_gmm.c:1047 -> ATTACH COMPLETE <0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS <0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS <0012> gprs_bssgp.c:347 BSSGP TLLI=0xf8bb36bb Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x478a8dCMD=UI DATA //remark: is a repetition of ATTACH COMPLETE <0013> gprs_llc.c:525 TLLI=f8bb36bb dropping UI, N(U=1) not in window V(URV(UR:2). <0012> gprs_bssgp.c:347 BSSGP TLLI=0xf8bb36bb Rx UPLINK-UNITDATA <0013> gprs_llc.c:478 LLC SAPI=1 C FCS=0x29e399CMD=UI DATA <0002> gprs_gmm.c:782 -> GMM DETACH REQUEST TLLI=0xf8bb36bb type=GPRS detach <0002> gprs_gmm.c:425 <- GPRS DETACH ACCEPT <0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS <0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS <0012> gprs_bssgp.c:523 BSSGP BVCI=2 Rx Flow Control MS
We see some dropped frames here which are in fact retransmissions sent by the Nokia device. After the successful GPRS Attach, the Nokia device refuses to send an ACTIVATE PDP Context REQ. Most Nokia devices get asked for IMSI and IMEI during the GPRS ATTACH, which her does not happen. However, these retransmissions are characteristical for all Nokia devices I've tested so far (6021, C5, C7, E65, 3109c).
Is there a timing problem between osmo-sgsn and Nokia devices? Can I tune osmo-sgsn's parameters to make the connection work?
Any help would be appreciated.
cheers
Olaf
----------------------------------------
hi Olaf,
On Fri, May 04, 2012 at 02:25:28PM +0200, Olaf Schulz wrote:
I use OpenBSC/GPRS (sw version only few weeks old) with nanoBTS and this works well mith many mobile devices. With Nokia devices, however, I do not get a PDP context. Here is an osmo-sgsn trace of Nokia E65:
This is very likely a problem related to TLLI state tracking and LLC sequence numbers. We have seen this for probably something like one year in OsmoSGSN and sadly nobody has had enough of a problem with it to actually debug it completely, fix it and contribute back a fix :/
Our own development is very much oriented towards features and fixes that are required/requested by our own customers, and none of them is using OsmoSGSN outside of a lab context, i.e. where those bugs would cause a major inconvenience.
I guess it would require something like one day of focussed work to get those TLLI and LLC sequence number issues sorted out.
Regards, Harald
On Fri, May 4, 2012 at 7:39 PM, Harald Welte laforge@gnumonks.org wrote:
hi Olaf,
On Fri, May 04, 2012 at 02:25:28PM +0200, Olaf Schulz wrote:
I use OpenBSC/GPRS (sw version only few weeks old) with nanoBTS and this works well mith many mobile devices. With Nokia devices, however, I do not get a PDP context. Here is an osmo-sgsn trace of Nokia E65:
This is very likely a problem related to TLLI state tracking and LLC sequence numbers. We have seen this for probably something like one year in OsmoSGSN and sadly nobody has had enough of a problem with it to actually debug it completely, fix it and contribute back a fix :/
Please see my posts from a few days back in which a fix is suggested for the TLLI mismatch. I had similar problems and they were solved after applying that patch. The problem, as far as I found it, is that SGSN is translating the foreign TLLI to a local TLLI (which is fine), but later on rechecks the foreign TLLI for existence (which is not fine, because the local variant exists). In my patch I convert all TLLI to local before doing a check so previously created local TLLI's are matched to the correlated foreign TLLI.
Regards, Frank
-
Harald Welte -
Olaf Schulz -
VID - Frank Maas