OpenBSC March 2023

openbsc@lists.osmocom.org

8 participants
13 discussions

by Mychaela Falconia

Hello GSM community, Would anyone in either of the two sub-communities of GSM (OsmoCNI and FC) happen to have a working setup with an ip.access nanoBTS, specifically with working voice calls? For the purpose of this inquiry, that "working setup" can be either with Osmocom CNI sw or with whatever original proprietary sw was once "official" for these ip.access nanoBTS units. If anyone does have a working nanoBTS setup with any sw, would you be willing to produce and share a packet capture (pcap file) of a working voice call, particularly the RTP stream originating from the nanoBTS? I am particularly interested in seeing a nanoBTS-generated RTP stream in either FR1 or EFR codec, as opposed to AMR or HR, coming from a GSM call UL with DTX enabled - having a 'dtx uplink' line in OsmoBSC config under 'bts N' should do it. The reason for my interest? I am looking to see what the pre-existing (before Osmocom) implementation of GSM-UL-to-RTP conversion in nanoBTS does in the two corner cases of (1) the MS exercising DTX during speech pauses and (2) speech frame 20 ms windows on TCH UL being stolen for FACCH. In case 1, does nanoBTS produce an intentional gap in its transmitted RTP stream (no packets sent at all) like OsmoBTS does, or does it do something different? Does it perhaps send RTP packets with zero-length payload, or some in-band bit pattern that is meant to indicate "bad frame, no data"? Case 2 is also interesting: current osmo-bts-trx (based on my reading of code, no hw to test on) invokes FR1 ECU and emits its output in this case, whereas stock (without my hacky patches) osmo-bts-sysmo exhibits an outright bug whereby nothing is emitted on RTP during the FACCH-stolen 20 ms window, and that gap in the RTP stream is NOT accounted for in the timestamps of subsequent RTP packets. Once again, I can only wonder what the pre-Osmocom implementation in nanoBTS does in this case. I would really like to produce a clean, potentially-mergeable patch to OsmoBTS and submit it to Gerrit, a patch that would add vty config settings selecting among several possible behaviours for RTP output in cases of DTX silence, FACCH stealing or bad radio Rx - but I really need to know what the different "reasonable" behaviour choices are, and I feel that we as in FOSS GSM community also need to know what our proprietary predecessors did in this area. I am not able to test this nanoBTS behaviour myself because even though I have nanoBTS hw (one PCS1900 unit and one GSM850), I have had no success in getting it to work with Osmocom - and my troubleshooting attempts hit a brick wall when the misbehaviour appears to be somewhere in the proprietary black box of nanoBTS. Hence I really need help from someone in the community who does have a working nanoBTS setup (with any sw) and who could make some test voice calls (ideally one FR1 and one EFR, but even just one of these two codecs would be interesting to see) with an RTP packet capture running, and then share the resulting pcap file. During that test voice call, it would be ideal if the tester could alternate between speaking and silence, and also cause some FACCH activity, perhaps by pressing DTMF keys. M~

2 years, 4 months

ttcn3-bts-test regressions

by Vadim Yanitskiy

Hi all, I was planning to do this long time ago, but somehow kept leaving this for later. Today I revisited the state of ttcn3-bts-test, which shows quite a few regressions. I believe they need to be investigated and eventually fixed, so I created several tickets for tracking these regressions in Osmocom's Redmine: * OS#5951: TC_early_immediate_assignment, * OS#5952: TC_ho_physical_info, * OS#5953: TC_ms_pwr_ctrl_{constant,pf_ewma}, * OS#5954: TC_pcu_data_ind_lqual_cb, * OS#5955: TC_pcu_[ext_]rach_content, TC_pcu_ptcch, * OS#5956: TC_rsl_rf_resource_ind. The following tickets already existed prior to my checkup: * OS#4023: TC_pcu_oml_alert, * OS#5242: TC_ipa_crcx_ack_addr, * OS#5517: TC_tx_power_ramp_adm_state_change. So far this is all about non-hopping configuration: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… The freq. hopping configuration exhibits slightly more red TCs: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… 92% vs 84% passing TCs to be precise, but this is kinda expected because of the limitations we have in fake_trx: FAKE_* CTRL commands are applied to just one transceiver, not affecting others, which are also part of the Mobile Allocation. Mostly the meas related TCs are affected. The following TC groups are quite stable and mostly all green: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… The following two TC groups have never been stable/all green, AFAICT: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… We may want to create more tickets for those, maybe less granular (i.e. one ticket per group). I am not familiar with these two TC groups, so would be nice to get some input from those who write them. What would it take to get them fixed? Are there any tickets already? If could not find any, but I only did a quick search. Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at 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

2 years, 4 months

OsmoDevCall on Mar 15, 2023: Circuit Switched Data (CSD) in GSM

by Harald Welte

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: March 15, 2023 at 20:00 CET where: https://osmocom.org/OsmoDevCall (Big Blue Button) This time, @laforge be presenting on Long range communications in the HF band CSD is the mechanism by which circuit-switched data calls can be made over classic GSM/2G (and later also UMTS/3G) networks. They resembled the modem call of circuit-switched networks, but of course no voiceband modem is involved. For more information, see our CSD wiki page at https://osmocom.org/projects/cellular-infrastructure/wiki/CSD This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation as outlined above 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you soon! Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 5 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC March 2023