OpenBSC May 2017

openbsc@lists.osmocom.org

26 participants
60 discussions

how to use the CTRL interface to set TRAPs.
by emily mcmilin 20 Jun '17

20 Jun '17

Hi all, I have some uncertainty about how to use the CTRL interface to set TRAPs. In the OsmoBSC user manual (for example), the example provided doesn't specify an option to set for the 'var' I might be particularly interested in monitoring: `$ ./bsc_control.py -d localhost -m` Is this the default to monitor all? Can I go about narrowing this? Also, I don't feel like I quite understand the TRAP portion of "Table 2: Variables available over control interface" in the OsmoBSC user manual: For example, the 'name' column seems to generally indicate the 'var' that one would pass in a GET/SET command, so I'm assuming the 'name' associated with the TRAP-enabled rows has the same significance. But these 'names' have no real meaning to me in terms of my experience with VTY, for example 'notification'. I have tried to look toward the osmo-nitb unit tests for inspiration, as there is fantastic coverage for GET/SET, out haven't seen similar for TRAP. Can someone please point me in the right direction? Thanks, Emily

3 9

Voice audio testing in osmo-gsm-tester
by Harald Welte 12 Jun '17

12 Jun '17

Dear all, osmo-gsm-tester is currently capable of setting up an entire network with one or more BTSs, Modems, NITB, etc. and test signaling + SMS. Voice testing has always been on the wishlist, but further down on the TODO list. One issue here is that a) many modems don't do voice at all (data-only modems for laptops) b) some modems expose voice only as analog audio (difficult to interface, would require custom hardware next to the modem, e.g. using USB soundcard, calibrate the levels, ...) c) some modems expose the voice as PCM bus. Similarly, would require some external codec chip and/or USB soundcard or the like, plus a custom circuit d) some modems expose voice as "GSM codec frames over UART" or other highty proprietary formats e) some modems expose voice as USB audio device. Most convenient, but only found in some Qualcomm LE based devices such as Sierra Wireless or Quectel. Over the weekend I was thinking of yet another method to make this much simpler: Every phone is supposed to include a voice loop-back mode. In this mode, the phone siply loops back all voice frames received in the downlink and sends them back in the uplink. This functionality is mandatory by the spec, and used to test the receiver performance of the phone during development, manufacturing and service. IT is specified in 3GPP TS 44.014 (http://www.etsi.org/deliver/etsi_ts/144000_144099/144014/14.00.00_60/ts_144…) which used to be GSM TS 04.04 (http://www.etsi.org/deliver/etsi_ts/101200_101299/101293/08.06.00_60/ts_101…) before. The idea is that one puts a special "Test SIM" (as specified in TS 51.010-1 Annex 4, where EF.AD first byte == 0x80 is the criteria in this context) into the phone, and then sends some specific commands on Layer3 to activate the loop. So if we can activate that loop-back functionality from the Osmocom stack, we could test if we get back the same voice data that we send in downlink (minus some occasional bit error, but those should be super low given we're operating omso-gsm-tester over coaxial cabling between MS and BTS). 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)

4 8

Proposal: Usage of stow in jenkins build scripts
by Alexander Huemer 10 Jun '17

10 Jun '17

Hi, The osmocom software that I do not install via apt but build myself gets installed in $HOME/usr and I do things like: export PATH="${PATH}:${HOME}/usr/bin" export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${HOME}/usr/lib" export PKG_CONFIG_PATH=$HOME/usr/lib/pkgconfig MANPATH="${MANPATH}:${HOME}/usr/man" Therefore I don't have to install to a destination outside my home directory which in turn means I can avoid some sudo calls. But that actually does not matter so much, you can mentally substitute $HOME with '/' and append '/local' in the following if you want. I don't install to $HOME/usr directly but use stow for 'managing' the installations, so an installation goes like this: $ mkdir -p $HOME/src/telco/osmo/libosmo-abis $ cd $HOME/src/telco/osmo/libosmo-abis $ git clone git://git.osmocom.org/libosmo-abis $ autoreconf -i $ ./configure --prefix=$HOME/usr/stow/libosmo-abis $ make $ make install $ STOW_DIR=$HOME/usr/stow stow libosmo-abis This has two advantages: * Good visibility of what is installed by a package. $ tree $HOME/usr/stow/libosmocore * Possibility of uninstalling a package even if the Makefile is not present. For me those two advantages outweigh the small additional effort of using stow. Because of that workflow I sometimes run into situations in which make runs fail because either header files are not found during compilation or libraries are not found during linking. The reason is that autotools variables pointing to pkgconfig supplied directories point to a destination under the prefix path with which configure was called. If a dependency was not mentioned in a Makefile.am the required files are not found because the other dependencies are in other directories. For a system on which the osmocom-own dependency libs are installed in distinct directories, current openbsc master HEAD requires the attached patch for a build to succeed. I admit that in most situations the dependencies are installed in the same directory so this does not matter, but it is still a small bug. Therefore I propose to modify the jenkins build scripts so that they use distinct, stow managed directories for the dependencies. That should help to detect oversights, although admittedly developers would have to adapt their workflows to use stow as well in their daily hacking. Otherwise an oversight would be detected by jenkings and not locally which in turn would require additional cleanup commits which is not so nice. What is your gut feeling? Does the increased correctness of Makefiles.am contents justify the (IMO rather small) additional effort of using stow? Kind regards, -Alex

2 5

osmo-trx: Generating frame sync output on GPIO?
by Harald Welte 08 Jun '17

08 Jun '17

Hi all, I was wondering if it is possible to generate a TDMA frame sync output on a GPIO line of a USRP device (and/or any other SDR supported by osmo-trx). This way it would be much easier to do e.g. BER testing by using a pure waveform/pattern generator for the "MS side". Such devices (Like an E4433B) can only generate the uplink bursts with pseudo-random sequence, but they don't have any receiver, so they're not able to receive the downlink from the BTS in order to lock on the TDMA frame and transmit the uplink in sync to that. There are of course specialized devices (CMU-300, ...) or hardware options that add such receivers for synchronization on the signal generators, equipment side, but why go there if there would be an easy way to generate some kind of a frame sync output. I would appreciate to know even if there's a way to introduce such "synchronous GPIO toggles" or the like in the command stream to UHD devices. If that existed, it should be rather simple to insert those whenever a new burst for TS0 is sent. A rather computationally (and bandwidth) expensive other option might be to use the second RF output to generate such a signal, but I was hoping not having to abuse the 2nd channel for that ;) 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)

2 1

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

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

02 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 01 Jun '17

01 Jun '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 01 Jun '17

01 Jun '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 30 May '17

30 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC May 2017