OpenBSC June 2016

openbsc@lists.osmocom.org

18 participants
84 discussions

Splitting out M3UA and MTP3 out of Open BSC into a separate library
by Arran Cudbard-Bell 20 Nov '25

20 Nov '25

Hi, Developing a module for FreeRADIUS to support EAP-SIM and EAP-AKA authentication against a HLR. The HLR we were targeting only supported a SCTP/M3UA/SCCP/TCAP/MAP stack, so we couldn't use SUA. Ripping the M3UA/MTP3 code out of OpenBSC worked surprisingly well. We ended up running the event loop in a separate thread to work around the threading issues. Unfortunately the HLR implements the ANSI variant of everything, whereas OpenBSC and supporting libraries seem to have been written to be compatible with the ITU standards. ...but the differences are fairly minor at MTP3 and SCCP layers, and i've started work on a patchset for libosmo-sccp. https://gerrit.osmocom.org/#/c/73/ Anyway, trying to gauge interest in splitting those layers out of Open BSC into a separate library, would be happy to take on M2UA as well for consistency. It would almost certainly get more projects using the code. There's very little out there even in Perl land for working with SS7. Thanks, -Arran Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

6 6

GPRS - local and foreign TLLIs
by Luca Melette 18 Nov '25

18 Nov '25

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

4 5

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 07 Jul '25

07 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

dynamic traffic channels
by Neels Hofmeyr 20 May '25

20 May '25

On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels

3 5

Moving from trac to a single redmine
by Holger Freyther 25 Sep '16

25 Sep '16

Hi guys, I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now. Tickets: Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either: * not import tickets * only import from one project * deal with changing ticket numbers In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number? Wiki: We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this? kind regards holger

6 15

GPRS on osmo-trx not working
by Neels Hofmeyr 11 Jul '16

11 Jul '16

Hi List, Voice is working well, but I can't seem to get GPRS working on osmo-trx. I used the standard debian 8.4 packages for UHD which seem to work, and documented that at http://osmocom.org/projects/osmotrx/wiki/OsmoTRX#Dependencies I also tried to use a PCU from before EDGE support was merged, so that's not causing it. Any ideas on what might be causing this? With sysmobts, for example, I needed to configure the pcu with --enable-sysmocom-dsp. Any such things with osmo-trx? I'm running both pcu and osmo-bts-trx as root with -r 1. Some of the log messages look quite bad, like 20160628170840743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 I didn't do the rts-advance increase by 5, because when that log message is issued, the PCU is not running yet: 20160628170837632 DL1C <0006> scheduler.c:240 Prim for trx=0 ts=0 at fn=272652 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=272658) Below are some logs and attached are the config files. The identical setup is working for other BTS models, the osmo-bts.cfg is the only difference. Thanks for any hints! ~Neels TRX: linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0-unknown opening configuration table from path :memory: Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 1 EDGE support............ Disabled External Reference...... Disabled C0 Filler Table......... Disabled Diversity............... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 -- Operating over USB 2. -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 32.000000 MHz -- Actually got clock rate 32.000000 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Asking for clock rate 26.000000 MHz -- Actually got clock rate 26.000000 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting B210 4 SPS -- Transceiver active with 1 channel(s) NOTICE 140232141276928 17:27:18.0 Transceiver.cpp:241:start: Starting the transceiver NOTICE 140232141244160 17:27:18.5 Transceiver.cpp:380:pushRadioVector: dumping STALE burst in TRX->USRP interface ^ I see ~130 of these notices of a stale burst, but all with an identical timestamp, and only once after osmo-bts-trx starts up. PCU: 20160628170840742 DL1IF <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS 20160628170840742 DL1IF <0001> osmobts_sock.cpp:285 osmo-bts PCU socket has been connected 20160628170840742 DL1IF <0001> pcu_l1_if.cpp:359 BTS available 20160628170840742 DNS <0008> gprs_ns.c:233 NSVCI=65534 Creating NS-VC 20160628170840742 DNS <0008> gprs_ns.c:233 NSVCI=1800 Creating NS-VC 20160628170840742 DNS <0008> gprs_ns.c:1568 NSEI=1800 RESET procedure based on API request 20160628170840742 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170840742 DL1IF <0001> pcu_l1_if.cpp:83 Sending activate request: trx=0 ts=5 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:486 PDCH: trx=0 ts=5 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:83 Sending activate request: trx=0 ts=6 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:486 PDCH: trx=0 ts=6 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:83 Sending activate request: trx=0 ts=7 20160628170840743 DL1IF <0001> pcu_l1_if.cpp:486 PDCH: trx=0 ts=7 20160628170843743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170846743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170849743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170852743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170855743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170858743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170901743 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170904744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170907744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170910744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170913744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170916744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170919744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170922744 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170925745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170928745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170931745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170934745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170937745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170940745 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) 20160628170943746 DNS <0008> gprs_ns.c:393 NSEI=1800 Tx NS RESET (NSVCI=1800, cause=O&M intervention) SGSN: <0010> gprs_ns.c:233 NSVCI=65534 Creating NS-VC 20160628170817898 DGPRS <000f> sgsn_main.c:361 VTY at 127.0.0.1 4245 20160628170817898 DGPRS <000f> sgsn_main.c:370 CTRL at 127.0.0.1 4251 20160628170817898 DLGTP <0023> gtp.c:701 GTP: gtp_newgsn() started 20160628170840743 DNS <0010> gprs_ns.c:233 NSVCI=65535 Creating NS-VC 20160628170840743 DNS <0010> gprs_ns.c:1262 Creating NS-VC for BSS at 10.9.1.120:23000 20160628170840743 DNS <0010> gprs_ns.c:834 NSVCI=65535(invalid) Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170840743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170840743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170840743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170843743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170843743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170843743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170843743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170846743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170846743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170846743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170846743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170847899 DGPRS <000f> gprs_sgsn.c:790 Checking for inactive LLMEs, time = 16442 20160628170849743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170849743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170849743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170849743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170852743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170852743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170852743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170852743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170855743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170855743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170855743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170855743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170858743 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170858743 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170858743 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170858743 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170901744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170901744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170901744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170901744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170904744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170904744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170904744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170904744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170907744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170907744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170907744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170907744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170910744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170910744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170910744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170910744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170913744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170913744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170913744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170913744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170916744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170916744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170916744 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170916744 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170917900 DGPRS <000f> gprs_sgsn.c:790 Checking for inactive LLMEs, time = 16472 20160628170919744 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170919744 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170919745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170919745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170922745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170922745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170922745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170922745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170925745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170925745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170925745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170925745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170928745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170928745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170928745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170928745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170931745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170931745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170931745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170931745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170934745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170934745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170934745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170934745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170937745 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170937745 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170937745 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170937745 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170940746 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170940746 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170940746 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170940746 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170943746 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170943746 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170943746 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170943746 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 20160628170946746 DNS <0010> gprs_ns.c:834 NSVCI=1800 Rx NS RESET (NSEI=1800, NSVCI=1800, cause=O&M intervention) 20160628170946746 DNS <0010> gprs_ns.c:654 NSEI=1800 Tx NS RESET ACK (NSVCI=1800) 20160628170946746 DNS <0010> gprs_ns.c:942 NSVCI=1800 Rx NS RESET ACK (NSEI=1800, NSVCI=1800) 20160628170946746 DNS <0010> gprs_ns.c:951 NS RESET ACK Discarding unexpected message for NS-VCI 1800 from SGSN NSEI=1800 osmo-bts-trx: [...] 20160628170836837 DOML <0001> oml.c:217 OC=CHANNEL INST=(00,00,06) Tx STATE CHG REP 20160628170836877 DOML <0001> oml.c:817 OC=CHANNEL INST=(00,00,07) SET CHAN ATTR (TSC = 7) 20160628170836877 DL1C <0006> scheduler.c:1273 Configuring multiframe with PDCH trx=0 ts=7 20160628170836877 DOML <0001> oml.c:884 ADM state already was Unlocked 20160628170836877 DOML <0001> oml.c:249 OC=CHANNEL INST=(00,00,07) AVAIL STATE Dependency -> OK 20160628170836877 DOML <0001> oml.c:256 OC=CHANNEL INST=(00,00,07) OPER STATE Disabled -> Enabled 20160628170836877 DPCU <0009> pcu_sock.c:627 PCU socket not connected, dropping message 20160628170836877 DOML <0001> oml.c:217 OC=CHANNEL INST=(00,00,07) Tx STATE CHG REP 20160628170836984 DL1C <0006> scheduler_trx.c:1433 GSM clock skew: old fn=272611, new fn=272536 20160628170837632 DL1C <0006> scheduler.c:240 Prim for trx=0 ts=0 at fn=272652 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=272658) 20160628170840742 DPCU <0009> pcu_sock.c:824 PCU socket connected to external PCU 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PDTCH on trx=0 ts=5 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PTCCH on trx=0 ts=5 20160628170840743 DRSL <0000> rsl.c:579 (bts=0,trx=0,ts=5,ss=0) not sending CHAN ACT ACK 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PDTCH on trx=0 ts=6 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PTCCH on trx=0 ts=6 20160628170840743 DRSL <0000> rsl.c:579 (bts=0,trx=0,ts=6,ss=0) not sending CHAN ACT ACK 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PDTCH on trx=0 ts=7 20160628170840743 DL1C <0006> scheduler.c:1310 Activating PTCCH on trx=0 ts=7 20160628170840743 DRSL <0000> rsl.c:579 (bts=0,trx=0,ts=7,ss=0) not sending CHAN ACT ACK 20160628170857756 DL1C <0006> scheduler_trx.c:907 Received incomplete PDTCH block ending at fn=276994 (42/104) for PDTCH 20160628170857756 DL1C <0006> scheduler_trx.c:921 Received bad PDTCH block ending at fn=276994 (42/104) for PDTCH 20160628170940774 DL1C <0006> scheduler_trx.c:907 Received incomplete PDTCH block ending at fn=286315 (3/104) for PDTCH 20160628170940775 DL1C <0006> scheduler_trx.c:921 Received bad PDTCH block ending at fn=286315 (3/104) for PDTCH 20160628170945250 DL1C <0006> scheduler_trx.c:907 Received incomplete PDTCH block ending at fn=287285 (37/104) for PDTCH 20160628170945250 DL1C <0006> scheduler_trx.c:921 Received bad PDTCH block ending at fn=287285 (37/104) for PDTCH -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

3 9

OsmoTRX / BER, RSSI and Link Quality
by Harald Welte 07 Jul '16

07 Jul '16

Hi Tom and List, we're currently introducing some code that will make more use of measurement related information associated with the PH-RACH.req and PH-DATA.ind coming from the PHY up into L2. The first part is to introduce a reasonable BER limit fo 17% for RACH ghost elimination, but I have more plans for unifying the measurement processing/generation accross all supported BTS models. For osmo-bts-{sysmo,lc15,octphy} it is clear to me how to get the related information on RSSI, BER and LinkQuality for each of the RACH and DATA indications from the PHY. However, how can I get the related information from osmo-bts-trx? osmo-bts-trx seems to lack any BER reporting toward the common part, which among other things is the reason why link/rate adaption in the PCU can not work with it. Could you sched some light on this? -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 4

error install openbsc
by sms makhof 05 Jul '16

05 Jul '16

Hi all I am installing OpenBSC.I just following http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC (I am just Building libosmocore, Building libosmo-abis, Building libosmo-netif, Building OpenBSC and install library.) But when I tried to run OpenBSC,I encounter with this error(problem). user12@ubuntu:~$ cd '/home/user12/openbsc/openbsc/src/osmo-nitb' user12@ubuntu:~/openbsc/openbsc/src/osmo-nitb$ sudo ./osmo-nitb <0005> bsc_init.c:492 Failed to parse the config file: 'openbsc.cfg' Or how do I run the software(OpenBSC)! Or do I have to install something missing? Note: My Linux is version ubuntu 12.04 . Please help me. thank you.

2 1

Is there a maximum separation in Mhz for ARFCNs on one BTS?
by Keith Whyte 01 Jul '16

01 Jul '16

Hi all, Would somebody who is familiar with the relevant part of the GSM spec be able to comment? I'm wondering if there's any issue in GSM running a dual TRX BTS with two ARFCNs on opposite ends of the band? For example, in GSM850, this would mean the downlinks could be on 869.2 and 893.8 Mhz so the phone could have to tune across a wider range between the SDCCH and TCH for example. Thanks!

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2016