OpenBSC May 2017

openbsc@lists.osmocom.org

26 participants
57 discussions

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

07 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 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

Re: OsmocomBB compile testing / Re: libosmocore embedded build
by Craig Comstock 29 May '17

29 May '17

I was thinking about how to setup an automated real device test for the repo and/or PRs especially. I have devices and cables, just was thinking about how to automate the re-loading of firmware (via an interface to the power button I suppose). Any work ongoing on this front? I'd be happy to contribute as I have a server I'm going to use for nano3g, calypsobts, development. -Craig -------------------------------------------- On Thu, 5/18/17, Harald Welte <laforge(a)gnumonks.org> wrote: Subject: OsmocomBB compile testing / Re: libosmocore embedded build To: "André Boddenberg" <dr.blobb(a)gmail.com> Cc: baseband-devel(a)lists.osmocom.org, "OpenBSC" <openbsc(a)lists.osmocom.org>, "Vadim Yanitskiy" <axilirator(a)gmail.com> Date: Thursday, May 18, 2017, 1:24 PM Hi Andre and others. We currently have a series of patches from Vadim pending in gerrit for OsmocomBB. They cannot move ahead, as we have no compile testing / jenkins job which would give this a +1. To resolve this, we should also start to have a jenkins compile testing job for OsmocomBB. The "host" (PC) part of the code is built against regular libosmocore, just like e.g. openbsc or osmo-bts. That should be possible even so far, and it might make sense to start with that. Basically you need to: * git clone osmocom-bb * cd src/host/layer23 * regular 'autoreconf -fi && ./configure && make' compile-testing the 'embedded' (firmware) part is not possible easily in the current master. However, as a second step, and after the libosmocore embedded build has run (and it is installed to /usr/local/arm-none-eabi), and if you use the laforge/remove-libosmocore branch in OsmocomBB, you should also be able to compile-test the firmware using * git clone osmocom-bb * cd src/target/firmware && make There currently is no "make check" tests for either the host utilities or the firmware, and of course we have no clue if the resulting binaries will do anything useful on an actual pone [yet!], but I still think the two steps above would be very useful to move ahead, and to unify the patch submission/review/verification/approval/merge process in gerrit with what we have established for the network-side projects like OsmoBTS & co. 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 2

m3ua and sua testing as part of jenkins?
by Harald Welte 29 May '17

29 May '17

Dear all, for some time, I've been wanting to have an easy way to run m3ua-testtool and sua-testtool as part of our regular regression testing setup. After some very disappointing trials using docker (see my blog), I managed to make this work using the 'unshare' program (part of util-linux). The key regquirement basically is: * create a network namespace * configure some netdevice / ip adresses in it * run the software under test (osmo-stp in this case) * run the test suite * tear down everything Initially I tried to do this using 'ip netns', but the problem is that you normally require root permissions to configure the netdevice inside the new namespace. And being root is of course difficult if you think of a jenkins build slave. However, 'unshare' offers the ability to map your real UID to root inside the namespace. At that point, everything can be done as non-root. The resulting scripts are in libosmo-sccp/contrib/test: "run-in-ns.sh" is a simple wrapper around unshare, so you have to call something like ./run-in-ns.sh ./test-m3ua.sh In order to use the m3ua-testtool, you will need to * install guile * clone + build + install https://github.com/nplab/guile-sctp * clone + build m3ua-testtool and sua-testtool from git.osmocom.org, no installation of this require. I would appreciate feedback from others trying to reproduce the above setup on their machine[s]. All tests should be GREEN/PASS. If anyone knowns how to integrate this with jenkins for libosmo-sccp,I think it would be great to have this as part of our testing of gerrit patches. I'm not so sure if it makes sense to try to integrate this with "make check", as it is not a unit test (and it would only work on Linux). I'm planning to use the saee "run-in-ns.sh" approach for my SCCP level tests implemented in TTCN-3/Titan. One further idea is if it make sense to report the test reuslts in a more friendly way. Right now it's deailed osmo-stp logs interspersed with output from the tester. Mayb there's some more information we can feed back into jenkins? Again, I have very little understanding of jenkins. 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 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC May 2017