OpenBSC

openbsc@lists.osmocom.org

4315 discussions

images
by Neels Hofmeyr 05 Jun '17

05 Jun '17

People keep posting images to this list. I saw that mailman allows to remove image attachments by file suffix and/or by mime type. I suggest we put jpg, png, bmp on the list of attachments to remove. AFAICT there was zero need for a legitimate image post, and if we'd want to we can always create a wiki page or redmine ticket and attach the image there. It would be nicer to bounce messages with such attachments completely, but dropping the attachments is the next best thing. Opinions? I don't have access to the list admin, so (if we agree) someone else would need to effect this / give me the pw: mailman admin / "MIME-/HTML-Filter" / tick 'yes' on top and add image suffixes to the reject list ~N

1 0

ipaccess 1800/1900 model
by Albert Paijmans 03 Jun '17

03 Jun '17

Hello, In the Netherlands the free gsm channel for private gsm networks is; 1875 - 1879,9 MHz 200 mW e.r.p. 200 kHz 875 - 1879,8 MHz 50 mW/MHz e.r.p. ≤4,5 MHz But I am a little bit confused as to how to set up an ipacces nanobts with those frequencies In OsmoBTS configuration file find bts 0 and set band to GSM1800 Also set frequencies to right value arfcn The example says ( https://osmocom.org/projects/openbsc/wiki/Multi-BTS_with_handover) trx 0 rf_locked 0 arfcn 74 ... trx 1 rf_locked 0 arfcn 84 --------------- I am not sure what to put at arfcn as the correct frequency with the mentioned frequency.. A second question, the nanoBTS comes in 1800 for GSM1800, and GSM1900 variant thereof (almost identical hardware) Well I can get 2 of the 1900 version very cheap from the USA but setting the configuration file bts 0 band GSM1800 won´t change the frequeny of the 1900 model to 1800MHz? Or can I only use the 1900 version in the free 1900MHz DECT frequency range? I have attached the official document of the Dutch regulatory body with the allowed frequencies, see page 28 for DECT frequencies in 1900 band and page 29 for picocell frequencies in the 1800 band. To me it seems both bands 1800 and 1900 are allowed, 1800Mhz is the official private gsm but for testing purposes using a 1900 model on the DECT band should be ok to. If the nanobts 1900 US model could also operate on the 1800 band that would be even better. Thanks, Albert

3 2

osmo-gsm-manuals DRAFT
by Neels Hofmeyr 03 Jun '17

03 Jun '17

In our osmo-gsm-manuals, there are various code listings that one would like to copy-paste from the PDF. That would theoretically work, but practically, the 'DRAFT' watermark in the backdrop confuses the text marking, hence making copy-pasting some text from the manuals very very cumbersome. Though I'm not that sure why we need a 'DRAFT' watermark in an open source manual (it's implicitly a draft), I am fine with having such a marking. But I would like the marking to be less obtrusive. We could experiment with putting a bitmap image in the backdrop instead of text, or even better IMHO would be to put it in the page header next to the version. We could also add a generic "DRAFT" disclaimer near the beginning of each document. (Same goes for the sysmocom internal manuals, for which it isn't so easy to get the asciidoc source to paste from.) Any opinions on this? ~N

2 3

libosmo-sccp: Build breakage on --disable-static
by Holger Freyther 03 Jun '17

03 Jun '17

Hi, I just looked into a build breakage when --disable-static is passed. The first failure is because of: libosmo_sigtran_la_LDFLAGS = -version-info $(LIBVERSION) \ -no-undefined \ -export-symbols-regex '^osmo_' The testcases use xua_* sua_ symbols but they are not exported. Shall we export them or shall we forbid --disable-static on libosmo-sccp? The second part is that I had preferred the sccp library to be static only to avoid having to do proper ABI checking/versioning. If we fix the above, maybe we have to fix this part too? holger

2 2

Initial Suggestion | Merging osmo-sim-auth and PySIM and update on MNCC with OsmocomBB
by Gerard Lawrence Pinto 01 Jun '17

01 Jun '17

Greetings, Congrats on OsmoCon 2017! I have been working with OsmocomBB, osmo-sim-auth, mncc-python projects in Osmocom. I would like to contribute some code snippets with your acceptance. To begin with I have committed: I) MNCC with OsmocomBB - *https://github.com/GerardPinto/call-control-mncc-sap <https://github.com/GerardPinto/call-control-mncc-sap>* (Has both implementations in Python and C + Tested voice with gsm-fr with gsm audio file - works great). - Some of which can be committed to mncc-python? (In order to support MNCC with OsmocomBB too) Although, Harald told me it was built for OpenNITB - I'm not sure, the relevance of this contribution to this repo? Reason: 1. Solves some mailing list questions: Some questions on mailing list are pertaining sending voice from PC to phone and receive. 2. Useful for test cases: In the future, if 'gsm-efr' codec is implemented, we can use these snippets and send audio with gsm-efr sample, instead of connecting to LCR (Am I correct?) *Issues faced*: File: l23api.c | function: l1ctl_rx_traffic_req() 264 bits (33 bytes) of voice codec are interleaved into 456 bits. The DAC, ciphering/deciphering , RF etc. work on 114 bits at a time so, 114 x 4 = 456. So Layer23 sends 4 - 114 bits into the queue to Layer1 in function => l1ctl_rx_traffic_req *Code*: num = l1a_txq_msgb_count(&l1s.tx_queue[L1S_CHAN_TRAFFIC]) if num > 4 dropping traffic frame. (114 x 4) The code above indicates if queue has any (114 x 4) bits drop the incoming voice request. So I faced the issue of voice packets getting dropped, but that was just twice/thrice and then it did not give me any trouble (I'm not sure how it got fixed), I could hear *clear* voice gsm-fr on the called party cell phone. *My Question is*: If I happened to send voice packets 33 bytes really fast. There should be some kind of buffer rather than a check (Code) and drop frame? - OR this case can never happen? My apologies, if my understanding is incorrect, I just tried to reverse engg. from code and GSM codec available online! II) osmo-sim-auth with added other SIM related API's (still needs code clean up, SIM response check, code re-usable, README.md etc,) * https://github.com/GerardPinto/osmo-sim-auth <https://github.com/GerardPinto/osmo-sim-auth> * - I did check out PySIM (I think I can add some code to the existing repository, with your permission). Could you please let me know if my osmo-sim-auth repo? If it is correct to combine with PySIM, with the changes done below? Files modified: 1. SIM.py - Added more API's. 2. osmo-sim-auth.py - Options parser. Thanks, Gerard.

3 3

Message Sequence Charts on A / SCCPlite / 3GPP AoIP
by Harald Welte 31 May '17

31 May '17

Dear all, today I put together some message sequence charges on the different A interface configurations. This should serve to establish some kind of "common understanding" about what is different in terms of a) classic A interface (E1 on Abis and A) b) Old OsmoBSC with Abis/IP and SCCPlite+MGCP on A c) New OsmoBSC with Abis/IP and 3GPP AoIP d) New OsmoBSC with Abis/E1 and 3GPP AoIP (extended MGW) The document is in gerrit review, but you can also find a rendered version of the current draft at http://people.osmocom.org/laforge/tmp/aoip-mgw-options.pdf Please let me know if your understanding of the different protocol/options is different. I'll continue to work on the document and add some more textual explanation. Regards, 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)

1 0

osmo-trx rx gain question
by Max 31 May '17

31 May '17

Hi. While testing latest osmo-trx in multi-trx mode I've noticed following errors: sudo chrt -r 99 ./Transceiver52M/osmo-trx -c 2 -x -m linux; GNU C++ version 6.2.0 20161005; Boost_106100; UHD_003.009.006-release opening configuration table from path :memory: Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in and supported by CPU Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 2 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ Disabled Reference............... External C0 Filler Table......... Disabled Multi-Carrier........... Enabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 -- Detected Device: B210 -- 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 16.000000 MHz... -- Actually got clock rate 16.000000 MHz. -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting master clock rate selection to 'automatic'. -- Asking for clock rate 51.200000 MHz... -- Actually got clock rate 51.200000 MHz. -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting B200/B210 4 SPS Multi-ARFCN -- Transceiver active with 2 channel(s) NOTICE 139729930782464 12:59:47.8 Transceiver.cpp:794:driveControl: Changing TSC from 0 to 7 NOTICE 139729930782464 12:59:47.8 Transceiver.cpp:243:start: Starting the transceiver NOTICE 139729930749696 12:59:48.0 Transceiver.cpp:794:driveControl: Changing TSC from 7 to 7 ALERT 139729930749696 12:59:48.0 UHDDevice.cpp:611:setRxGain: Requested non-existent channel 1 ALERT 139729930749696 12:59:48.0 UHDDevice.cpp:611:setRxGain: Requested non-existent channel 1 ... This doesn't seem to have any visible effect but still makes me wonder what's going on here? If this is indeed critical error than what exactly is broken and how to test it? If it's smth which could be safely ignored than why it's reported with alert priority? Any help clarifying it would be appreciated. -- Max Suraev <msuraev(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 * Geschaeftsfuehrer / Managing Director: Harald Welte

3 2

osmo-gsm-tester successfully runs {NITB, AoverIP} x {sysmoBTS, B210}
by Neels Hofmeyr 30 May '17

30 May '17

Just now I obtained a successful test run of the osmo-gsm-tester with these combinations: OsmoNITB with sysmoBTS OsmoNITB with osmo-bts-trx (Ettus B210) OsmoMSC + OsmoBSC (AoverIP) with sysmoBTS OsmoMSC + OsmoBSC (AoverIP) with osmo-bts-trx (Ettus B210) http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester… yay! :) All of these are now enabled by default. ~N -- - 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

2 1

PCU socket in OsmoNITB breaks osmo-gsm-tester
by Neels Hofmeyr 29 May '17

29 May '17

> commit b4999b60d48bcbb5aa575973d068e07ab672e095 > Author: Philipp Maier <pmaier(a)sysmocom.de> > Date: Wed Oct 26 15:19:41 2016 +0200 > > pcu_sock: add basic pcu interface support > > Adds a basic version of a pcu socket interface, similar > to the one that can be found in osmo-bts. > > Change-Id: Ib13cb4099d12fa71e9e0b8727e19ab29e11909b2 This commit adds PCU sockets to OsmoNITB, but these are not configurable, which is a problem for the osmo-gsm-tester. We cannot have separate OsmoNITB processes all write to /tmp/pcu_bts, their paths needs to be configurable. Also they seem to not be cleaned up when the process exits. I now see failures of OsmoNITB starting because the /tmp/pcu_bts is still present. This appears when a different user attempts to start an OsmoNITB, i.e. I had a successful run with the 'jenkins' user and am then trying as 'neels'. I guess the PCU socket file should be cleaned up on exit?? The third point is that I don't understand why the OsmoNITB or the OsmoBSC need PCU sockets. The commit log does not explain that unfortunately. I would like this commit to be reverted until the location is configurable, so that the osmo-gsm-tester can continue to run across several users. (and several NITBs at once, which we're not using yet, but in principle could want to.) I have a ticket for this in the OsmoGSMTester project, we may need to move it to a different parent project or create a new ticket: https://osmocom.org/issues/2293 ~N

2 5

static builds in jenkins
by Max 29 May '17

29 May '17

Hi. Most (if not all) of Osmocom libraries can be built for static linking. With the addition of https://gerrit.osmocom.org/#/c/2748/ we can leverage this to also build static OpenBSC which comes in handy while testing from time to time. Would be nice to add this option to jenkins as well (for OpenBSC as well as all the libraries). What do you think? -- Max Suraev <msuraev(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 * Geschaeftsfuehrer / Managing Director: Harald Welte

4 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC