OpenBSC July 2021

openbsc@lists.osmocom.org

10 participants
25 discussions

On the use of 'decmatch' in TTCN-3
by Harald Welte 27 Jan '26

27 Jan '26

Hi, I know that TTCN-3 is still new to a lot of you, but we are writing tons of integration testing against the various osmocom programs in it. It is quite amazing technology, and I would like to ask you to bear with me reading this mail :) Pau was stating the question earlier today on not finding an example on how to use decmatch. Indeed, it took me some months to find that gem in the TTCN-3 world. It solves the problem that you often have during test of layered protocol stacks: you have separate encoders/decoders for each protocol layer, and now you want to match on some of the *inner* payload. So normally, you have some kind of header definition + a binary (octetstring) payload. This happens in RSL with the L3_INFO IE, and just the same on BSSAP/DTAP where again the L3 message (for example call control) is encapsulated inside one information element. Now you have multiple options of addressing the problem: a) hand-written calls to the decoder function b) write na 'emulation' for the entire protocol layer c) use decmatch. a) would look like this (pseudo-code): var octetstring l3oct; var RSL_Message rsl RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, ?)) -> value rsl { var PDU_ML3_MS_NW l3 := dec_PDU_ML3_MS_NW(rsl.payload); if (match(l3, some_template)) { ... do something } ... } Which uses the built-in pattern-matching on the RSL port to match any message that matches the tr_RSL_DATA_REQ template, and stores the resulting RSL message in a variable. It then uses an explicit call to the decoder function of the L3 message, and then uses regular conditional expressions for further matching on that inner L3 payload. This is more or less how you would write in C, python or any other quite imperative programming languages. It's very verbose, time consuming and un-abstract/elegant. TTCN-3 has many declarative aspects to it. Code like the above is a waste of your time :) b) would mean that you implement some test component that handles the RSL messages on its bottom side test port, and the L3 messages on its top side test port. That is a possible way, and if you need a lot of state/logic of RSL, it maeks sense. But what if you really simply want to have a match? Then it would be a lot of effort and a large detour. c) decmatch to the rescue! You can write RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, decmatch tr_RRM_RR_STATUS)) which means: * do a receive on the RSL test port, and match on an incoming RSL message that matches the tr_RSL_DATA_REQ template, with channel number specified, link_id any (?), *and* if the octetstring payload, if decoded, matches the template tr_RRM_RR_STATUS ! This is *extremely* powerful and expressive. It allows you to condense complex, parametric template matching over multiple proocol layers. It would in the end match RSL DATA REQUEST, only if they contained a [valid] encoded RR STATUS. See https://gerrit.osmocom.org/6229 for the actual test case I used for the above examples. Please also note that I never had to even write the function name of the decoder (dec_PDU_ML3_MS_NW), but TTCN-3 *automatically* figures out which decoder function it must call in order to decode from the binary octetstring. Happy (TTCN-3) hacking + Osmocom bugfixing, Harald -- - 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 3

osmo-gsm-manuals in project repos: I see no .pdf
by Neels Hofmeyr 08 Jan '26

08 Jan '26

Hi Oliver, so I merged the stuff to add the manuals to the individual git repositories, since you said that it works. But when I do --enable-manuals I don't see any PDF files generated. Also a manual 'make pdf' says "nothing to be done". (I probably should have tried it before merging after all) So what am I doing wrong? Alternatively, can you fix it please? ~N

3 3

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

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

Problem while running NIB on Open Cellular Base sation
by Brackley Casinga 31 Jan '24

31 Jan '24

Hi, My name is Brackley Cassinga Form DRC, we run a community network called pamoja net where we offer gsm services using osmocom open source software and OC Base station. Recently I have tried to install another base station as the same installed but I could not find any resource guiding through all the steps to take to run NIB on a base station. I'm currently running Ubuntu and I will appreciate if you could guide me on the installation of BSC,hlr,MSC , in order to run a basic gsm network. Thank you. Regards -- *Ir Brackley heshima Casinga **Pacifique* *CEO and Founder of kwanzatechnologie* KwanzaTechnologies ,GlobalElectronics +243977265291 | +243977265291 | Pcassinga(a)gmail.com/ brackley(a)ensemblepourladifference.org www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> | Skype: Brackley cassinga <https://webapp.wisestamp.com/#> Av Semliki N 43

2 1

Can't establish calls between two handsets [nanoBTS 165AU]
by Sebastian Mauer 02 Aug '21

02 Aug '21

Hello there, In my lab I have access to an ip.access nanoBTS 165AU which I have setup with OsmoBSC. Sending SMS between my two test handsets (Nokia 105) are working fine, however it seems there is a problem when making calls. From the logs it seems the radio is unable to assign a TCH_F channel. Any idea what could be causing this and how I would debug this further? Cheers, Sebastian <0003> abis_rsl.c:1533 (bts=0) CHAN RQD: reason: call re-establishment (ra=0x49, neci=0x01, chreq_reason=0x02) <000f> lchan_select.c:262 lchan(0-0-0-CCCH_SDCCH4-0)[0xaaaadc4251c0]{UNUSED}: (type=SDCCH) Selected <000f> lchan_fsm.c:636 lchan(0-0-0-CCCH_SDCCH4-0)[0xaaaadc4251c0]{WAIT_TS_READY}: (type=SDCCH) Activation requested: FOR_MS_CHANNEL_REQUEST voice=no MGW-ci=none type=SDCCH tch-mode=SIGNALLING encr-alg=A5/0 ck=none <0007> osmo_bsc_sigtran.c:297 Initializing resources for new SCCP connection to MSC 0: RI=SSN_PC,PC=0.23.1,SSN=BSSAP... <0007> osmo_bsc_sigtran.c:343 Opening new SCCP connection (id=4) to MSC 0: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0007> osmo_bsc_bssap.c:1147 Rx MSC DT1 BSSMAP COMMON ID <0007> osmo_bsc_bssap.c:1251 Rx MSC DTAP, SAPI: RR/MM/CC CHAN: 0 <0007> gsm_08_08.c:567 Tx MSC DTAP LINK_ID=0x00 <0007> osmo_bsc_sigtran.c:383 Tx MSC: DTAP <0007> osmo_bsc_bssap.c:1251 Rx MSC DTAP, SAPI: RR/MM/CC CHAN: 2 <0007> osmo_bsc_bssap.c:1110 Rx MSC UDT BSSMAP PAGING <0007> osmo_bsc_bssap.c:126 (msc0) Paging: subscr-IMSI-901700000050081-TMSI-0x06e8ff82: (bts0) Paging on LAC 1 <0007> osmo_bsc_bssap.c:1147 Rx MSC DT1 BSSMAP ASSIGNMENT REQ <000f> lchan_select.c:262 lchan(0-0-2-TCH_F-0)[0xaaaadc432ba0]{UNUSED}: (type=TCH_F) Selected <0011> assignment_fsm.c:570 assignment(msc0-conn4_subscr-IMSI-901700000050080-TMSI-0xbf4aa84d_0-0-2-TCH_F-0)[0xaaaadc43e930]{WAIT_LCHAN_ACTIVE}: (bts=0,trx=0,ts=2,ss=0) Starting Assignment: chan_mode=SPEECH_V1, chan_type=FR, aoip=yes MSC-rtp=192.168.148.159:4074 (osmux=no) <000f> lchan_fsm.c:636 lchan(0-0-2-TCH_F-0)[0xaaaadc432ba0]{WAIT_TS_READY}: (type=TCH_F) Activation requested: FOR_ASSIGNMENT voice=yes MGW-ci=new type=TCH_F tch-mode=SPEECH_V1 encr-alg=A5/0 ck=none <000f> lchan_fsm.c:81 lchan(0-0-2-TCH_F-0)[0xaaaadc432ba0]{WAIT_RLL_RTP_ESTABLISH}: (type=TCH_F) lchan-rtp failure in state WAIT_IPACC_CRCX_ACK: Received NACK on IPACC CRCX <000f> lchan_fsm.c:81 lchan(0-0-2-TCH_F-0)[0xaaaadc432ba0]{WAIT_RLL_RTP_ESTABLISH}: (type=TCH_F) lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Failed to setup RTP stream: LCHAN_EV_RTP_ERROR in state WAIT_RLL_RTP_ESTABLISH <000f> lchan_fsm.c:116 lchan(0-0-2-TCH_F-0)[0xaaaadc432ba0]{WAIT_RLL_RTP_ESTABLISH}: (type=TCH_F) Signalling Assignment FSM of error (lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Failed to setup RTP stream: LCHAN_EV_RTP_ERROR in state WAIT_RLL_RTP_ESTABLISH ) <0011> assignment_fsm.c:821 assignment(msc0-conn4_subscr-IMSI-901700000050080-TMSI-0xbf4aa84d_0-0-2-TCH_F-0)[0xaaaadc43e930]{WAIT_RR_ASS_COMPLETE}: (bts=0,trx=0,ts=2,ss=0) Assignment failed in state WAIT_RR_ASS_COMPLETE, cause RADIO INTERFACE MESSAGE FAILURE: Failed to activate lchan (bts=0,trx=0,ts=2,ss=0) <0007> osmo_bsc_sigtran.c:379 Tx MSC: BSSMAP: ASSIGNMENT FAIL <0011> assignment_fsm.c:148 assignment(msc0-conn4_subscr-IMSI-901700000050080-TMSI-0xbf4aa84d_0-0-2-TCH_F-0)[0xaaaadc43e930]{WAIT_RR_ASS_COMPLETE}: (bts=0,trx=0,ts=2,ss=0) Assignment failed <0007> osmo_bsc_bssap.c:1251 Rx MSC DTAP, SAPI: RR/MM/CC CHAN: 2 <0007> osmo_bsc_bssap.c:1147 Rx MSC DT1 BSSMAP CLEAR COMMAND <0007> osmo_bsc_sigtran.c:379 Tx MSC: BSSMAP: CLEAR COMPLETE <0005> paging.c:84 (bts=0) Going to send paging commands: subscr-IMSI-901700000050081-TMSI-0x06e8ff82 for ch. type 0 (attempt 0) <000f> gsm_04_08_rr.c:1021 lchan(0-0-0-CCCH_SDCCH4-0)[0xaaaadc4251c0]{WAIT_BEFORE_RF_RELEASE}: (type=SDCCH) Got data in non active state, discarding. <0005> paging.c:84 (bts=0) Going to send paging commands: subscr-IMSI-901700000050081-TMSI-0x06e8ff82 for ch. type 0 (attempt 1) <0005> paging.c:84 (bts=0) Going to send paging commands: subscr-IMSI-901700000050081-TMSI-0x06e8ff82 for ch. type 0 (attempt 2) <0003> abis_rsl.c:1533 (bts=0) CHAN RQD: reason: answer to paging (ra=0x9f, neci=0x01, chreq_reason=0x01) <000f> lchan_select.c:262 lchan(0-0-0-CCCH_SDCCH4-1)[0xaaaadc425390]{UNUSED}: (type=SDCCH) Selected <000f> lchan_fsm.c:636 lchan(0-0-0-CCCH_SDCCH4-1)[0xaaaadc425390]{WAIT_TS_READY}: (type=SDCCH) Activation requested: FOR_MS_CHANNEL_REQUEST voice=no MGW-ci=none type=SDCCH tch-mode=SIGNALLING encr-alg=A5/0 ck=none <0005> paging.c:84 (bts=0) Going to send paging commands: subscr-IMSI-901700000050081-TMSI-0x06e8ff82 for ch. type 0 (attempt 3) <0007> osmo_bsc_sigtran.c:297 Initializing resources for new SCCP connection to MSC 0: RI=SSN_PC,PC=0.23.1,SSN=BSSAP... <0007> osmo_bsc_sigtran.c:343 Opening new SCCP connection (id=5) to MSC 0: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0007> osmo_bsc_bssap.c:1147 Rx MSC DT1 BSSMAP COMMON ID <0007> osmo_bsc_bssap.c:1147 Rx MSC DT1 BSSMAP CLEAR COMMAND <0007> osmo_bsc_sigtran.c:379 Tx MSC: BSSMAP: CLEAR COMPLETE <0003> abis_rsl.c:1533 (bts=0) CHAN RQD: reason: answer to paging (ra=0x88, neci=0x01, chreq_reason=0x01) <000f> lchan_select.c:262 lchan(0-0-0-CCCH_SDCCH4-0)[0xaaaadc4251c0]{UNUSED}: (type=SDCCH) Selected <000f> lchan_fsm.c:636 lchan(0-0-0-CCCH_SDCCH4-0)[0xaaaadc4251c0]{WAIT_TS_READY}: (type=SDCCH) Activation requested: FOR_MS_CHANNEL_REQUEST voice=no MGW-ci=none type=SDCCH tch-mode=SIGNALLING encr-alg=A5/0 ck=none <0007> osmo_bsc_sigtran.c:297 Initializing resources for new SCCP connection to MSC 0: RI=SSN_PC,PC=0.23.1,SSN=BSSAP... <0007> osmo_bsc_sigtran.c:343 Opening new SCCP connection (id=6) to MSC 0: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0007> osmo_bsc_bssap.c:1147 Rx MSC DT1 BSSMAP COMMON ID <0007> osmo_bsc_bssap.c:1147 Rx MSC DT1 BSSMAP CLEAR COMMAND <0007> osmo_bsc_sigtran.c:379 Tx MSC: BSSMAP: CLEAR COMPLETE

3 4

MS Power Transmit not changing
by Sonny Lafuente 30 Jul '21

30 Jul '21

Hello Neels and Community, Good day! We are doing some testing on our Lab specifically in Voice. During this testing we observed that the MS power transmit is not changing during ongoing call and the value is 5dbm. We also do walk test in order to lower the received power level and to observed if the MS Transmit power will increase. We tried to change some parameters in osmo-bts-trx uplink-power-target but however, the MS Transmit power still the same which is 5dbm. The MS power in the osmo-nitb config is set to 23dbm. Below is the version and configuration we used on our testing in Lab. Version: OpenBSC# show version OpenBSC 1.3.2.2-d2550 (OpenBSC). Copyright (C) 2008-2016 Harald Welte, Holger Freyther Contributions by Daniel Willmann, Jan Lübbe, Stefan Schmidt Dieter Spaar, Andreas Eversberg, Sylvain Munaut, Neels Hofmeyr License AGPLv3+: GNU AGPL version 3 or later <http://gnu.org/licenses/agpl-3.0.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. OpenBSC# OsmoBTS# show version OsmoBTS 1.2.0.48-6392 (OsmoBTS). Copyright (C) 2010, 2011 by Harald Welte, Andreas Eversberg and On-Waves License AGPLv3+: GNU AGPL version 3 or later <http://gnu.org/licenses/agpl-3.0.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. OsmoBTS# Logs: OpenBSC# show lchan BTS 0, TRX 1, Timeslot 0, Lchan 0: Type SDCCH Connection: 1, State: ACTIVE BS Power: 0 dBm, MS Power: 23 dBm Channel Mode / Codec: signalling Subscriber: ID: 1816, Authorized: 0 Extension: 164324 IMSI: 515039102991665 Use count: 1 Bound IP: 0.0.0.0 Port 0 RTP_TYPE2=0 CONN_ID=0 Measurement Report: Flags: DLinval RXL-FULL-ul: -50 dBm, RXL-SUB-ul: -50 dBm RXQ-FULL-ul: 7, RXQ-SUB-ul: 7 BTS 0, TRX 1, Timeslot 6, Lchan 0: Type TCH_F Connection: 1, State: ACTIVE BS Power: 0 dBm, MS Power: 23 dBm Channel Mode / Codec: FR or HR Subscriber: ID: 1782, Authorized: 1 Extension: 05837654321 IMSI: 515032920153135 Use count: 2 Bound IP: X.X.X.X Port 16386 RTP_TYPE2=0 CONN_ID=0 Measurement Report: Flags: MS Timing Offset: 0 L1 MS Power: 5 dBm, Timing Advance: 0 RXL-FULL-dl: -47 dBm, RXL-SUB-dl: -47 dBm RXQ-FULL-dl: 0, RXQ-SUB-dl: 0 RXL-FULL-ul: -47 dBm, RXL-SUB-ul: -47 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 BTS 0, TRX 1, Timeslot 7, Lchan 0: Type TCH_F Connection: 1, State: ACTIVE BS Power: 0 dBm, MS Power: 23 dBm Channel Mode / Codec: FR or HR Subscriber: ID: 4, Authorized: 1 Extension: 05831234567 IMSI: 515032919099978 Use count: 2 Bound IP: X.X.X.X Port 16384 RTP_TYPE2=0 CONN_ID=0 Measurement Report: Flags: MS Timing Offset: 0 L1 MS Power: 5 dBm, Timing Advance: 0 RXL-FULL-dl: -47 dBm, RXL-SUB-dl: -47 dBm RXQ-FULL-dl: 4, RXQ-SUB-dl: 5 RXL-FULL-ul: -47 dBm, RXL-SUB-ul: -47 dBm RXQ-FULL-ul: 7, RXQ-SUB-ul: 7 OpenBSC# Ongoing Call Logs: OpenBSC# show lchan summary BTS 0, TRX 1, Timeslot 6 TCH/F, Lchan 0, Type TCH_F, State ACTIVE - L1 MS Power: 5 dBm RXL-FULL-dl: -47 dBm RXL-FULL-ul: -47 dBm BTS 0, TRX 1, Timeslot 7 TCH/F, Lchan 0, Type TCH_F, State ACTIVE - L1 MS Power: 5 dBm RXL-FULL-dl: -47 dBm RXL-FULL-ul: -47 dBm OpenBSC# Osmo-BTS current config: e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive phy 0 osmotrx ip local 127.0.0.1 osmotrx ip remote 127.0.0.1 no osmotrx ms-power-loop osmotrx base-port local 5800 osmotrx base-port remote 5700 osmotrx fn-advance 20 osmotrx rts-advance 5 instance 0 osmotrx rx-gain 0 osmotrx tx-attenuation 13 osmotrx maxdly 0 instance 1 osmotrx rx-gain 0 osmotrx tx-attenuation 10 osmotrx maxdly 0 bts 0 band GSM900 ipa unit-id 1000 0 oml remote-ip x.x.x.x rtp jitter-buffer 100 paging queue-size 200 paging lifetime 0 uplink-power-target -75 gsmtap-sapi ccch gsmtap-sapi pdtch min-qual-rach 50 min-qual-norm -5 max-ber10k-rach 1707 trx 0 power-ramp max-initial 0 mdBm power-ramp step-size 2000 mdB power-ramp step-interval 1 ms-power-control dsp phy 0 instance 0 trx 1 power-ramp max-initial 0 mdBm power-ramp step-size 2000 mdB power-ramp step-interval 1 ms-power-control dsp phy 0 instance 1 Osmo-Nitb Current Config: root@ubuntu:/etc/osmocom# cat osmo-nitb.cfg ! log stderr logging filter all 1 logging color 1 logging print category 0 logging timestamp 1 logging level all everything logging level rll notice logging level cc notice logging level mm notice logging level rr notice logging level rsl notice logging level nm info logging level mncc notice logging level pag notice logging level meas notice logging level sccp notice logging level msc notice logging level mgcp notice logging level ho notice logging level db notice logging level ref notice logging level gprs debug logging level ns info logging level bssgp debug logging level llc debug logging level sndcp debug logging level nat notice logging level ctrl notice logging level smpp debug logging level filter debug logging level ranap debug logging level sua debug logging level pcu debug logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice logging level lstats notice logging level lgsup notice logging level loap notice logging level lss7 notice logging level lsccp notice logging level lsua notice logging level lm3ua notice logging level lmgcp notice ! stats interval 5 ! line vty no login ! e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive network network country code 10 mobile network code 1 short name testnetwork long name testnetwork auth policy closed authorized-regexp .* location updating reject cause 13 encryption a5 0 neci 1 paging any use tch 0 rrlp mode none mm info 1 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 timer t3113 60 timer t3103 1 timer t3101 10 timer t3109 1 timer t3122 10 timer t3105 1 dyn_ts_allow_tch_f 0 subscriber-keep-in-ram 1 bts 0 type sysmobts band GSM900 cell_identity 1 location_area_code 1 base_station_id_code 63 ms max power 23 cell reselection hysteresis 4 rxlev access min 0 periodic location update 30 radio-link-timeout 32 channel allocator descending rach tx integer 9 rach max transmission 7 channel-descrption attach 1 channel-descrption bs-pa-mfrms 5 channel-descrption bs-ag-blks-res 1 early-classmark-sending forbidden ip.access unit_id 1000 0 oml ip.access stream_id 255 line 0 neighbor-list mode automatic codec-support fr hr efr amr amr tch-h modes 0 amr tch-h start-mode auto gprs mode gprs gprs 11bit_rach_support_for_egprs 0 gprs routing area 1 gprs network-control-order nc0 gprs cell bvci 2 gprs cell timer blocking-timer 3 gprs cell timer blocking-retries 3 gprs cell timer unblocking-retries 3 gprs cell timer reset-timer 3 gprs cell timer reset-retries 3 gprs cell timer suspend-timer 10 gprs cell timer suspend-retries 3 gprs cell timer resume-timer 10 gprs cell timer resume-retries 3 gprs cell timer capability-update-timer 10 gprs cell timer capability-update-retries 3 gprs nsei 101 gprs ns timer tns-block 3 gprs ns timer tns-block-retries 3 gprs ns timer tns-reset 3 gprs ns timer tns-reset-retries 3 gprs ns timer tns-test 30 gprs ns timer tns-alive 3 gprs ns timer tns-alive-retries 10 gprs nsvc 0 nsvci 101 gprs nsvc 0 local udp port 23000 gprs nsvc 0 remote udp port 23000 gprs nsvc 0 remote ip 127.0.0.2 gprs nsvc 1 nsvci 0 gprs nsvc 1 local udp port 0 gprs nsvc 1 remote udp port 0 gprs nsvc 1 remote ip 0.0.0.0 no force-combined-si trx 0 rf_locked 0 arfcn 122 nominal power 0 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config SDCCH8 hopping enabled 0 timeslot 2 phys_chan_config SDCCH8 hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 trx 1 rf_locked 0 arfcn 42 nominal power 0 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 mncc-int default-codec tch-f fr default-codec tch-h amr nitb subscriber-create-on-demand subscriber-create-on-demand random 100000 199999 no assign-tmsi smpp local-tcp-ip 127.0.0.1 2776 system-id password policy closed smpp-first esme admin password password default-route Rootubuntu:/etc/osmocom# Regards, Sonny Lafuente | Systems Engineer | Entropy Solution Philippines Mobile: +639985365206 | Office: 028931781 | Email: sonny.lafuente(a)entropysolution.com<mailto:sonny.lafuente@entropysolution.com> Office Address: Unit 2103 Antel Corporate Centre 121 Valero St. Salcedo Village Makati City Philippines 1227 [cid:936BCCE1-8AAB-4E96-8413-E1075D00DBE3] Singapore * Philippines Products: Gridloc*Intelle*Hype*Lighthouse*Telco Services*Software Development This email (including any attachment to it) is confidential and intended only for the use of the individual named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message (including any attachment to it). Thank you.

2 1

(no subject)
by Henry Caga 26 Jul '21

26 Jul '21

Hi, I would like to know if it is possible to disconnect a connected device to my osmo-bsc system? After running my osmo-bsc setup and my test phone is connected to my usrp via 2g, is it possible to send a vty command or what are the steps to make the connected device to detach to my bts? Thank you so much. Hnjojo

3 4

Announcement of "OsmoDevCall" on July 23, 2021
by Harald Welte 22 Jul '21

22 Jul '21

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at July 23, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation on "high-level overview on IMS, VoLTE, VoWiFi" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2021