OpenBSC March 2018

openbsc@lists.osmocom.org

16 participants
30 discussions

OsmoBsc_Nat with osmux configuration example

by Rafael Diniz

Hi all, Does anyone have a working OsmoBsc_Nat with osmux working example? I just want to take a look in osmux, so it doesn't matter if it's with old NITB-era stack or new split stack. Thanks, Rafael Diniz

7 years, 3 months

MS driver: GSM tester config integration

by Holger Freyther

Hey, pespin left a good comment about the question of how the MS driver and the GSM tester could be better integrated. I was about to write some argparse code for the MS driver but I think it is best to make this configurable as a scenario. In terms of scenario knobs I can see: - #MS - CDF function - IMSI generator (start with XXX and count upwards) - virtphy vs. trxcon? The actual test would remain separate (and maybe turn it into a suite at some point in the future). What do you think? What should I obey when parsing/handling config? holger

7 years, 3 months

GSM tester scenarios and beyond

by Holger Freyther

Hey neels, pespin, while looking at configuration handling for the MS driver I started to have sone questions about scenarios. I see that we have multiple yaml files and through scenarios can control ciphering, the timeslot configuration, which BTS model to test, and more. What would it take to get this abstraction one step further? When I diff the aoio_sms and sms suite the difference is in setup (and then naming of msc vs. nitb)? Wouldn't this be something we can get into the scenario as well? The requirements for this test are two connected and routable subscribers? low priority thing but what do you think? holger

7 years, 3 months

fsm4 branch and handover_test.c

by Neels Hofmeyr

Hi Philipp, I promised you to look at handover_test.c on the new fsm4 branch. Looking at it now, I immediately ran into FSM events being dropped on the floor because it was in the wrong state. When I initially fix that, the test runs into the MGCP FSM not existing. So at the end of the day, it is all related to the recently added FSMs and how they interact, and it seems to me that you are more familiar with those than me. In other words, I'm playing the ball back into your corner now: Look at osmo-bsc branch neels/fsm4, here are the differences to pmaier/fsm4: - right at the start, I add a patch to properly wrap abis_rsl_sendmsg(). That's just cosmetic, really. It was doing its job well, just I don't trust that implicit linking. It's at the start because I also submitted it to gerrit. 5eaaf6120e21 (I'd link to git.osmocom.org but after 10 minutes the branch still isn't synced there, strange.) - I add the DMSC logging category to handover_test.c. That enables the FSM's error messages to be logged. This only makes sense as long as that FSM is actually logging on DMSC, which doesn't seem a good fit. 8128a49a6c6ce4ae - I kick the gscon into the ACTIVE state when a conn is created. That might be taking a shortcut, since I'm not sure how e.g. the conn->user_plane.fi_bts should be populated... c2f90c36c445b2a38 So, e.g. when running './handover_test 1', my code state enabled the logging for them and uncovered the errors: DMSC handover_logic.c:135 SUBSCR_CONN[0x564f2a1d3b70]{INIT}: Event HO_START not permitted and then DMSC handover_logic.c:135 SUBSCR_CONN[0x564f2a1d3b70]{WAIT_CC}: Event HO_START not permitted These two are fixed, and now I'm stuck at: DMSC handover_logic.c:333 SUBSCR_CONN[0x560525a1cb70]{WAIT_HO_COMPL}: Received Event HO_COMPL DMSC bsc_subscr_conn_fsm.c:710 SUBSCR_CONN[0x560525a1cb70]{WAIT_HO_COMPL}: state_chg to WAIT_MDCX_BTS_HO Assert failed fi ../../../../src/osmo-mgw/src/libosmo-mgcp-client/mgcp_client_fsm.c:603 i.e. the handover_test.c is trying to indicate a 'Handover Complete' to the libbsc machinery by calling handover_test.c:send_ho_complete(), and it runs into a wall of the fake conn having conn->user_plane.fi_bts == NULL. At this point I could start figuring out how to fake the fi_bts, but in fact I assume you're more proficient in that area, so please take over from here. Thanks! ~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

7 years, 3 months

osmo-trx and limesdr mini

by Cyril

Hello, I wonder if someone has got the limesdr mini (hardware v1.1, gateway 1.24) running with osmo-trx ? I've been able to get it working with the non-mini version (the "big" mimo limesdr) but with the mini version it crashes after a few tenth seconds with apparently something going wrong on the tx side (see attachments) Any feedback is welcomed :) Cyril

7 years, 3 months

osmo-trx commit 3da1f83

by Cyril

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

7 years, 3 months

Submissions for OsmoDevCon 2018

by Harald Welte

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)

7 years, 3 months

TTCN-3 test suite for OsmoBTS

by Harald Welte

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)

7 years, 3 months

Re: trxcon, fake-trx and osmo-bts-trx: Simulating TA + Power Control

by Vadim Yanitskiy

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.

7 years, 3 months

A5/1 Encryption Enabled - Programmable SIM unable to camp

by Ron

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>

7 years, 3 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC March 2018