OpenBSC October 2015

openbsc@lists.osmocom.org

17 participants
43 discussions

GPRS - local and foreign TLLIs
by Luca Melette 04 Feb '26

04 Feb '26

Hello everybody, after setting up a nanoBTS with OpenBSC/SGSN/GGSN, I had some troubles trying to connect my smartphone to the GPRS cell. Investigating the BTS-to-SGSN traffic, I saw that the frames sent by the SGSN were all marked with the same N(U) value (at LLC layer), the value was 0. With some debug, I found that the there was a mismatch in the TLLI storage, used to keep the status of attached terminals. The mentioned code is contained in gprs_llc.c, involving LL Entity functions and gprs_llc_tx_ui(). /* look-up or create the LL Entity for this (TLLI, SAPI) tuple */ lle = lle_by_tlli_sapi(msgb_tlli(msg), sapi); if (!lle) { struct gprs_llc_llme *llme; LOGP(DLLC, LOGL_ERROR, "LLC TX: unknown TLLI 0x%08x, " "creating LLME on the fly\n", msgb_tlli(msg)); llme = llme_alloc(msgb_tlli(msg)); lle = &llme->lle[sapi]; } The TX function uses the previously received TLLI to lookup for the LLE. The lle_by_tlli_sapi() performs the search, but preliminary it applies a foreign2local TLLI conversion to ensure to have a local one. Since no valid entry for the searched TLLI is found, a new one is created. And the problem is here. The new entry has the foreign TLLI. Next time the lookup fails again, and a new entry is created. This way, the counter N(U) is always reset, and the mobile do not recognize the message sequence and no attach is possible. My question is about foreign and local TLLIs. I patched the lookup, avoiding the conversion, so that the LLE is found and everything works fine... but... What is the sense of the conversion? Should the TLLI be always stored as a local one? Can this problem be solved with another foreign2local while allocating new entries? Actually, my problem has been solved with that workaround. But I'm curious to know what is the right way. Hope somebody can answer :) Thanks. Cheers, LM

5 6

Pysim error: SW match failed
by Martin Nagy 16 Aug '25

16 Aug '25

Hi all, After buying a super Sim Kit (16 in 1) from China, I tried the reader (green PCB inside a blue transparent plastic case with a blue LED) and SIM (identified as a fakesupersim) with pysim tool. However i am getting the following error: /pySim-prog.py -n 26C3 -c 49 -x 262 -y 42 -z 1234 -j 1 -t auto Insert card now (or CTRL-C to cancel) Autodetected card type fakemagicsim Generated card parameters : > Name : 26C3 > SMSP : e1ffffffffffffffffffffffff058100945555ffffffffffff000000 > ICCID : 8949262427518313026 > MCC/MNC : 262/42 > IMSI : 262422461512085 > Ki : 7b74741a1ee14337ec23f9ab92a13648 > OPC : ccd867d60797d8d45354a51b3ef568ff Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 530, in <module> card.program(cp) File "/home/nadicek/pysim/pysim/pySim/cards.py", line 231, in program self._scc.update_binary('6f30', hplmn + 'ff' * (tl-3)) File "/home/nadicek/pysim/pysim/pySim/commands.py", line 53, in update_binary return self._tp.send_apdu_checksw(pdu) File "/home/nadicek/pysim/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed ! Expected 9000 and got 9804. I checked mailing lists and haven’t found anybody who had similar problem with pysim. Also I have tried forcing different models of SIM, but nothing is working. Obviously I can remove this check from the script file (__init__.py in /pySim/transport), however somebody had a reason to put such condition there. I would like to ask if it is safe to remove that line of code and the purpose of that line of code. Thanks a lot and best regards Martin

3 3

Re: Help with sccp library
by mosbah abdelkader 08 Jul '25

08 Jul '25

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

4 3

Half sided calls
by Sipos Csaba 30 Apr '16

30 Apr '16

Dear List, I am in the process of creating the Wiki page for Ettus B200/B210 with OpenBSC, GPRS and Asterisk. I am quite close, both data and calls are working, but the voice calls are half sided. The downlink direction works, but the uplink does not. I tried without Asterisk and LCR (between two phones) and still the calls are half sided. In the mean time I got these messages in the Osmo-BTS log: <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284768 ts=2 tr x=0 <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284764 to transmit. <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284764 to transmit. <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=1284772 ts=1 trx= 0 <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=1284772 ts=1 tr x=0 <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x0a fn=1284772 ts=2 trx= 0 <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284772 ts=2 tr x=0 <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284768 to transmit. <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284768 to transmit. SMS and GPRS seems to be fine. If someone have any idea, I would love to hear it. :-) Thanks! Csaba

5 10

[PATCH 0/4] core/conv: Fast Viterbi decoding
by Thomas Tsou 27 Apr '16

27 Apr '16

Hi all, This patch set adds to libosmocore an optimized Viterbi decodeer for architecture specific (Intel SSE) and non-specific cases. The implementation covers codes with constraint lengths of K=5 and K=7 and rates 1/4 to 3/4, which make up the majority of GSM use cases. Speedup from the current implementation is in the range of 5 to 20 depending on the processor and code type. API is unchanged. Tested on Haswell (i7-4770K) and Atom (D2550). Additional test codes from osmo-bts are included. Further tests for AWGN bit-error-rate and benchmarks can be found in the following repository. https://github.com/ttsou/osmo-conv-test Here are some examples. Bit error test for GPRS CS2 with SNR of 5 dB and 100000 bursts. $ ./conv_test -c 2 -e -r 5 -i 100000 ================================================= [+] Testing: GPRS CS2 [.] Specs: (N=2, K=5, non-recursive, flushed, not punctured) [.] Input length : ret = 290 exp = 290 -> OK [.] Output length : ret = 588 exp = 588 -> OK [.] BER tests: [..] Testing base: [..] Input BER.......................... 0.042443 [..] Output BER......................... 0.000006 [..] Output FER......................... 0.001350 (135) [..] Testing SIMD: [..] Input BER.......................... 0.042460 [..] Output BER......................... 0.000005 [..] Output FER......................... 0.001240 (124) Timed AFS benchmark with 8 threads and 100000 bursts per thread. $ ./conv_test -b -c 10 -j 8 -i 100000 ================================================= [+] Testing: GSM TCH/AFS 6.7 [.] Specs: (N=4, K=5, recursive, flushed, punctured) [.] Input length : ret = 140 exp = 140 -> OK [.] Output length : ret = 448 exp = 448 -> OK [.] Performance benchmark: [..] Encoding / Decoding 800000 bursts on 8 thread(s): [..] Testing base: [..] Elapsed time....................... 4.320001 secs [..] Rate............................... 25.925920 Mbps [..] Testing SIMD: [..] Elapsed time....................... 0.458272 secs [..] Rate............................... 244.396341 Mbps [..] Speedup............................ 9.426718 -TT

5 13

Meas_web and meas_json
by Sipos Csaba 01 Dec '15

01 Dec '15

Hi Alexander, Just wanted to thank you for the web version of meas_vis utility, and wanted to confirm that it works very well with Nokia Site family (E1 based) and the USRP B200 too :-) If someone missed it, the web version can be found here: https://github.com/fairwaves/meas_web It would make life easier if the meas_json utility would make it to the master branch: http://cgit.osmocom.org/openbsc/log/?h=achemeris/meas_json Is there a reason it is not being merged? Regards, Csaba

3 8

[PATCH 1/3] mncc: Implement helper functions to convert MNCC cause to a string.
by Alexander Chemeris 26 Nov '15

26 Nov '15

This is the first patch of the series. The first two patches are improvements of the log output and are independent of the 3rd patch in terms of code - proposed logging improvements just make it easier to debug issues with MNCC cause codes. The code is also a part of the achemeris/mncc_cause_fixes_master branch. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co

2 3

[PATCH 3/3] mncc: Send "Dest OOO" cause in case of a link radio failure.
by Alexander Chemeris 24 Nov '15

24 Nov '15

Previously we were sending a generic "Resource unavailable" cause code making it impossible to distinguish real error cases from a regular radio link failure. This was the reason for many "unknown" call errors we've seen at Rhizomatica installations. Now they are properly classified as non-erroneous call failures. The code is also a part of the achemeris/mncc_cause_fixes_master branch. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co

1 2

[PATCH 2/3] mncc: Log CC cause when sending a primitive to MNCC.
by Alexander Chemeris 24 Nov '15

24 Nov '15

The code is also a part of the achemeris/mncc_cause_fixes_master branch. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co

1 1

EGPRS(EDGE) data rate is not stable?
by wangpalm 21 Nov '15

21 Nov '15

With phone attached to my configured EGPRS, sometimes it has a data rate around 200kbps (which is near optimal), while frequently it has a intolerablly slow data rate. Is it a common problem, or it's due to incorrect configrations or hardware problems? I run a gsm test system with nanobts, and the libosmocore, openbsc, openggsn codes are based on the version around end of April 2015. The configuration is made accorrding to the instruction from openbsc web. The correction in fc_queue_timer_cfg has also been made according to Jacob Erlbeck.

3 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC October 2015