OpenBSC March 2018

openbsc@lists.osmocom.org

16 participants
35 discussions

osmo-trx commit 3da1f83
by Cyril 05 Mar '18

05 Mar '18

Hello, How do you select the log level with the libosmocore logging system introduced in commit 3da1f83 ? What is the equivalent of '-l DEBUG' command line option now ? Thanks ! Cyril

2 2

Submissions for OsmoDevCon 2018
by Harald Welte 04 Mar '18

04 Mar '18

Dear Osmocom community, it's already end of January and OsmoDevCon 2018 in April is getting closer and closer. As indicated before, I would like to group the topics by days and put together at least a rough framework shcedule, so that people with specific interests don't have to be present for four full days to make sure they don't miss anything. So I'd like to re-invite all attendees to consider adding a topic/porposal to the wiki page at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2018#section-9 so that we can group different topic areas and put together a rough schedule outline. A proposal doesn't mean you have to give a talk. It could be anything, including * a talk that you would want to listen to, and you're looking for somebody to give it * a discussion about a certain topic * a workshop / hands on session * lightning talks? Like any community event, OsmoDevCon lives by its contributors. I can't wait to hear about all the things you've been up to. Thanks! 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 1

TTCN-3 test suite for OsmoBTS
by Harald Welte 01 Mar '18

01 Mar '18

Hi all, today I've docker-ized the latest TTCN-3 test suite I've been developing over the last week or so. They're now running nightly in our Jenkins, you can see the results analyzer at https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/test_resu… (don't forget the "Expand All" button) Out of all the test suites I've written in recent months, the OsmoBTS test suite is what I'm particularly happy about. While of course not achieving 100% coverage it actually tests a lot of things, including various cases that would be very hard to impossible to achieve in manual testing.o A larger number of tests is also relate to the BTS<->PCU socket interface, where [almost] each of the message types occurring in Rx/Tx is triggered + tested accordingly. The system information scheduling test cases were working for me 2 days ago, I'm not sure what I did wrong to break them again, I'll investigate. In terms of important needed OsmoBTS tests, I see: * verification of PCU -> Um for all different coding schemes (requires PDCH support in trxcon first, or fall-back to virt_phy instead) * testing of timing advance loop * testing of uplink power control loop (needs fake_trx extension) * testing of voice channels in all codec modes * memory leak related testing It was a loooong week full of late night and early morning shifts, but I'm happy that progress was possible in a rather short amount of time. Thanks to Vadim "fixeria" for his work on trxcon + fake_trx, which means we can test a fully unmodified osmo-bts-trx ("the real thing"), rather than osmo-bts-virtual, which is a BTS model that doesn't exist this way in reality. The nice part is that the test cases only use L1CTL on one hand side and RSL/PCUIF/VTY/CTRL on the other side, and as such they should in theory work equally with the followign setups: a) TTCN3 -L1CTL-> trxcon -> fake_trx -> osmo-bts-trx -> TTCN3 (current) b) TTCN3 -L1CTL-> virt_phy osmo-bts-virtual -> TTCN3 c) TTCN3 -L1CTL-> OsmocomBB-firmware -RF-> osmo-bts-{sysmo,lc15,octphy} -> TTCN3 Only 'a)' is currently used, but it would definitely be interesting to be able to use the exact same test cases (minus TA/power-control loop test) with real hardware and the different PHYs. Any contributions are as always very much welcome. With all the existing test cases out there and the dockerized setup, it should be super easy to reproduce the test results on your local machine, and to copy+paste+edit an existing test to extend test coverage even further. The development of the test suite has already resulted in dozens (!) of bugs being discovered some of them quite severe. Check the increased activity since february 22nd at http://osmocom.org/projects/osmobts/issues?utf8=%E2%9C%93&set_filter=1&f%5B… for more information 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

Re: trxcon, fake-trx and osmo-bts-trx: Simulating TA + Power Control
by Vadim Yanitskiy 01 Mar '18

01 Mar '18

Hi Harald, > fake_trx must be able to insert additional false "delay" > ... > 1) Implementation of TA in fake_trx > ... > 2) implementation of "fake delay" in fake_trx > ... Done. Great collaborative work! > fake_trx must be able to insert additional false "path loss" > ... > For RSSI processing it's slightly more complicated: This needs to be discussed. > fake_trx would need to know the nominal transmit power > of both MS and BTS. For this example, let's assume MS > nominal power is +30dBm and BTS +23 dBm... Do we really need to specify the nominal transmit power for both? At the moment, trxcon is capable to parse the L1CTL_PARAM_REQ messages from the higher layers, and it basically forwards exactly TX power instead of TX attenuation to transceiver... Or should we change this value to attenuation, and go by the way you suggested above? This task doesn't seem too complicated, so I'll implement this. By the way, I have another idea. We are talking about path loss, which does not only affect power levels, but also introduces some bit corruption level. This could be also simulated in FakeTRX, but first of all, it's good to know, do we need this feature? I think it makes sense, because a MS also reports BER in its Measurement Reports. With best regards, Vadim Yanitskiy.

1 0

A5/1 Encryption Enabled - Programmable SIM unable to camp
by Ron 01 Mar '18

01 Mar '18

Hi All, Does anyone tried enabling the A5/1 Encryption using osmo-bsc and osmo-msc? We are using an UPBOARD with the following elements; osmo-bsc, osmo-bts-trx and osmo-trx in it; and a NUC with osmo-hlr, osmo-msc, osmo-mgcp, and osmo-stp. Both servers are using Ubuntu 16.04 OS. We enabled the a5/1 encryption in both osmo-bsc and osmo-msc. Then provisioned the programmable SIM to osmo-hlr with aud2g comp128v1 auth. OsmoHLR# subscriber imsi 515941234567890 show ID: 9 IMSI: 515941234567890 MSISDN: 09271234567 2G auth: COMP128v1 KI=00112233445566778899aabbccddeeff We are not really sure what causes the LOCUP Reject. Can anyone help us with this issue? Attached are the configuration used during the testing and a trace taken during the testing. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC March 2018