OpenBSC October 2018

openbsc@lists.osmocom.org

28 participants
29 discussions

by Neels Hofmeyr

[private hacking hat on] Thinking ahead to the 35C3, I have tinkered with IuUP a bit. I'm at the point where I have an IuUP core net node in the osmo-mgw, which auto-detects IuUP peers and removes IuUP headers coming from a 3G RNC, and inserts IuUP headers in RTP going to a 3G RNC. So far we were merely hacking over the IuUP header to mimick an Initialization ACK, and were otherwise just handing the IuUP headers through from one 3G peer to the other. I realized now that hacking up an Initialization ACK like we currently do on osmo-mgw master produces a header CRC error, which the femto cells we currently tested completely don't care about, thankfully. Ok, so now I am de/encapsulating the IuUP from/to RTP, so that IuUP is present only on the last leg to/from an RNC. 3G to 3G calls still work well with that, now also having correct IuUP header CRCs. And, the naive idea was that now the 2G would simply understand the RTP from the 3G and vice versa. But that's not the case, apparently. The phones at best crackle some random artifacts. I picked a codec-list of fr3 hr3 in osmo-bsc, and tried a few AMR rates (12.2k, 5.9k, 5.2k). So I think there's still some fundamental concept that I'm lacking. Is there anyone more familiar with AMR and/or the way 3G encodes audio, and whether there's a simple way to make them match? Where should I read on? Would a call router like we use in the C3 POC be able to transcode when the IuUP is stripped? (I'm not even sure what the POC side is doing to connect SIP with GSM.) I've noticed the laforge/iu_up branch in libosmocore only later, which includes an FSM that apparently does only state transitions so far. My patch has no FSM yet, since all I see on the wire is Init->InitAck, then Data PDUs, and maybe an occasional error report. Do those FSM states convey a secret of making 3G encoding readable by 2G? Various pcaps of the status quo are here: http://kleinekatze.de/eeD0ouCo/ My IuUP branch: osmo-mgw neels/iuup http://git.osmocom.org/osmo-mgw/log/?h=neels/iuup IuUP protocol spec: 3GPP TS 25.415 (I've so far ignored most of it) ~N

6 years, 8 months

Persistent VTY history?

by Keith

Hi all. Was just thinking today about if it was ever considered to write the VTY history out to a file on exiting (and load it on startup) I'm quite the fan of the up arrow and it's been something that sometimes annoys that I have no history after leaving the VTY. It would seem reasonably trivial to implement, and I suppose you could write out to files in $HOME/.osmo-bsc_history or $HOME/.config or somesuch. Just wondering if this was ever discussed before, if there's any unforseen problem with it on my part + if it would be a desirable feature for anybody else? k/

6 years, 8 months

SMS handing in the Osmocom CNI

by Vadim Yanitskiy

Dear all, In this mail I would like to negotiate and discuss some details about further development of the Osmocom CNI, in particular the way of handling of SMS messages. At this time, all SMS messages within the Osmocom CNI are terminated at OsmoMSC. There we have some basic routing configuration, either internal, or SMPP. This approach has some disadvantages, at least: - MSC is not a proper place for terminating SMS messages, in commercial networks it's usually done by SMS Center; - in case if a network based on the Osmocom CNI does contain multiple MSCs, one has to configure / update the SMS routing configuration for each MSC individually; - one would have to use SMPP in order to deliver SMS messages to / from commercial networks, which in most cases "speak" either MAP, or DIAMETER, or even both, but not SMPP; - using SMPP (as it's the only external interface available) involves the need to encode and decode complex SMS protocol, what is not desired in some situations. This is why it was decided to rip the SMS routing out of OsmoMSC, and use generic (for Osmocom CNI) GSUP protocol as the transport. Please see OS#3587 for more details about "SMS over GSUP". So, we actually need a separate process, let's call it "OsmoSMSC" in quotes for now, as I am not sure about the proper name. It should implement at least basic functionality of the SMS Center. Since we are using OsmoHLR as the main / central gateway in the Osmocom CNI for all GSUP communications, this to be discussed "OsmoSMSC" should basically be connected to OsmoHLR. What I would like to discuss is how should we implement "OsmoSMSC"? I think there are two possible ways: either write it from scratch, or fork some existing project. Implementing from scratch would require much more efforts and time than forking an existing SMSC implementation, for sure. I've recently discovered a project called Kannel - an Open Source WAP and SMS gateway written in C and distributed under the Kannel Software License, please see: https://www.kannel.org/index.shtml What do I personally like: - helpers for OTA configuration (e.g. WAP, MMS settings) messages; - written in C and using automake as the build system; - high performance (hundreds of messages per second); - 7-bit, 8-bit and Unicode message coding. So we could fork this project as "OsmoSMSC", and extend in the following way: - integrate generic Osmocom logging; - integrate VTY interface and generic configuration; - implement GSUP client from OsmoHLR. I already started to read the source code and documentation. If anyone has any experience with Kannel, please share! And finally, how should we name "OsmoSMSC"? :) With best regards, Vadim Yanitskiy.

6 years, 8 months

IuUP, aka voice between 2G and 3G

by Neels Hofmeyr

Thinking ahead to the 35C3, I have tinkered with IuUP a bit. I'm at the point where I have an IuUP FSM which auto-detects IuUP peers and removes IuUP headers coming from a 3G RNC, and inserts IuUP headers in RTP going to a 3G RNC. So far we were merely hacking over the IuUP header to mimick an Initialization ACK, and were otherwise just handing the IuUP headers through from one 3G peer to the other. I realized now that hacking up an Initialization ACK like we currently do on osmo-mgw master produces a header CRC error, which the femto cells we currently tested completely don't care about, thankfully. Ok, so now I am de/encapsulating the IuUP from/to RTP, so that IuUP is present only on the last leg to/from an RNC. 3G to 3G calls still work well with that, now also having correct IuUP header CRCs. And, the naive idea was that now the 2G would simply understand the RTP from the 3G and vice versa. But that's not the case, apparently. The phones at best crackle some random artifacts. I picked a codec-list of fr3 hr3 in osmo-bsc, and tried a few AMR rates (12.2k, 5.9k, 5.2k). So I think there's still some fundamental concept that I'm lacking. Is there anyone more familiar with AMR and/or the way 3G encodes audio, and whether there's a simple way to make them match? Where should I read on? Would a call router like we use in the C3 POC be able to transcode when the IuUP is stripped? (I'm not even sure what the POC side is doing to connect SIP with GSM.) Various pcaps of the status quo are here: http://kleinekatze.de/eeD0ouCo/ My IuUP branch: osmo-mgw neels/iuup http://git.osmocom.org/osmo-mgw/log/?h=neels/iuup IuUP protocol spec: 3GPP TS 25.415 (I've so far ignored most of it) ~N

6 years, 8 months

OSMO-MSC/OSMO-HLR Auto Provisioning

by Ron

Hi Community, Is the auto provisioning (subscriber-create-on-demand) of OSMO-NITB is still present or available in OSMO-BSC/OSMO-MSC/OSMO-HLR version? We tried to use the “authentication optional” under OSMO-MSC configuration but still, it checks if the subscriber is provisioned in OSMO-HLR. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

6 years, 8 months

osmocom.org server upgrades

by Harald Welte

Dear all, I've just done one round of upgrades to our infrastructure, including gerrit, gitolite, cgit, patchwork, redmine, jenkins. Casual manual testing showed everything worked as expected at first sight. Particularly the jenkins upgrae might have some fall-out, as we're jumping 6 months of jenkins LTS releases in one step. Please report any issues to http://osmocom.org/projects/osmocom-servers/issues [or if that is broken, by e-mail here]. Thanks! -- - 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)

6 years, 8 months

Re: LimeSDR-USB experience with New Splits Solved!

by Vadim Yanitskiy

> Are you referring to the ones from 2015 or so with > Russian titles? Those are the only ones I am aware of Yes. There are few. Check out this one: https://youtu.be/jw-63aOOPk0 > how do you know that phone was running against an > Osmocom network [...] I know the author. Also, you can see the logs of OpenBSC on the background of the mentioned video. > The relation is simple: if phones like Mot C1xx running > Motorola's original factory fw don't work with Osmocom > networks, [...] In order to confirm, I just tested a Motorola C118 running the original firmware with Osmocom-based network. LimeSDR-Mini was used as PHY for OsmoTRX. Everything works fine, including: SDCCH: SMS, USSD, other signaling TCH/H: both HR and AMR codecs TCH/F: FR, AMR and EFR codecs Probably, the author of this topic has some problems with codec / network configuration. With best regards, Vadim Yanitskiy.

6 years, 8 months

UHD make failed with OsmoTRX/B210/Ubuntu 18.04

by Michael Benedict

Hi all, I'm trying to get OsmoTRX working with a B210 on Ubuntu 18.04. I recently posted to the USRP Users list but haven't had success yet, so posting here. Since the message below I've tried both the osmo-trx and osmo-trx-uhd binaries with several example config files on github. My next step will be to compile from source and try to debug the "UHD make" issue, but these binaries have worked for others so I hope I'm just missing something. Sincere thanks for any info. I'm new to this area but very excited to learn more. --Michael ---------------- .... Running the binary for osmo-trx on Ubuntu 18.04, I see: :~$ sudo osmo-trx linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown opening configuration table from path :memory: Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 1 EDGE support............ Disabled Reference............... Internal C0 Filler Table......... Disabled Multi-Carrier........... Disabled Diversity............... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 -- Detected Device: B210 -- Operating over USB 3. ALERT 140391490980800 13:45:44.2 UHDDevice.cpp:799:open: UHD make failed, device ALERT 140391490980800 13:45:44.2 UHDDevice.cpp:799:open: UHD make failed, device ALERT 140391490980800 13:45:44.2 osmo-trx.cpp:530:main: Failed to create radio device ALERT 140391490980800 13:45:44.2 osmo-trx.cpp:530:main: Failed to create radio device Shutting down transceiver... The output is similar with `sudo osmo-trx -a serial=31502DD`, and the output of uhd_find_devices looks normal to me: :~$ uhd_find_devices [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; UHD_3.13.0.1-release -------------------------------------------------- -- UHD Device 0 -------------------------------------------------- Device Address: serial: 31502DD name: MyB210 product: B210 type: b200 I get similar results with or without the suggested udev rules[1]. Looking at the osmo-trx source[2] I am confused why it would identify the device and then fail the UHD make step. It seems like `uhd::usrp::multi_usrp::make` throws exceptions if the device is not found. I've been stuck on this for a while and would appreciate any pointers or ideas of what else to try. In case it helps I'll include the output of uhd_usrp_probe. Thanks, --Michael [1] https://files.ettus.com/manual/page_transport.html [2] https://github.com/osmocom/osmo-trx/blob/74bcc562a9403e224c40a9db77753b81cd… ----- :~$ sudo uhd_usrp_probe [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; UHD_3.13.0.1-release [INFO] [B200] Detected Device: B210 [INFO] [B200] Operating over USB 3. [INFO] [B200] Detecting internal GPSDO.... [INFO] [GPS] No GPSDO found [INFO] [B200] Initialize CODEC control... [INFO] [B200] Initialize Radio control... [INFO] [B200] Performing register loopback test... [INFO] [B200] Register loopback test passed [INFO] [B200] Performing register loopback test... [INFO] [B200] Register loopback test passed [INFO] [B200] Setting master clock rate selection to 'automatic'. [INFO] [B200] Asking for clock rate 16.000000 MHz... [INFO] [B200] Actually got clock rate 16.000000 MHz. _____________________________________________________ / | Device: B-Series Device | _____________________________________________________ | / | | Mboard: B210 | | revision: 4 | | product: 2 | | serial: 31502DD | | name: MyB210 | | FW Version: 8.0 | | FPGA Version: 15.0 | | | | Time sources: none, internal, external, gpsdo | | Clock sources: internal, external, gpsdo | | Sensors: ref_locked | | _____________________________________________________ | | / | | | RX DSP: 0 | | | | | | Freq range: -8.000 to 8.000 MHz | | _____________________________________________________ | | / | | | RX DSP: 1 | | | | | | Freq range: -8.000 to 8.000 MHz | | _____________________________________________________ | | / | | | RX Dboard: A | | | _____________________________________________________ | | | / | | | | RX Frontend: A | | | | Name: FE-RX2 | | | | Antennas: TX/RX, RX2 | | | | Sensors: temp, rssi, lo_locked | | | | Freq range: 50.000 to 6000.000 MHz | | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB | | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | RX Frontend: B | | | | Name: FE-RX1 | | | | Antennas: TX/RX, RX2 | | | | Sensors: temp, rssi, lo_locked | | | | Freq range: 50.000 to 6000.000 MHz | | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB | | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | RX Codec: A | | | | Name: B210 RX dual ADC | | | | Gain Elements: None | | _____________________________________________________ | | / | | | TX DSP: 0 | | | | | | Freq range: -8.000 to 8.000 MHz | | _____________________________________________________ | | / | | | TX DSP: 1 | | | | | | Freq range: -8.000 to 8.000 MHz | | _____________________________________________________ | | / | | | TX Dboard: A | | | _____________________________________________________ | | | / | | | | TX Frontend: A | | | | Name: FE-TX2 | | | | Antennas: TX/RX | | | | Sensors: temp, lo_locked | | | | Freq range: 50.000 to 6000.000 MHz | | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB | | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | TX Frontend: B | | | | Name: FE-TX1 | | | | Antennas: TX/RX | | | | Sensors: temp, lo_locked | | | | Freq range: 50.000 to 6000.000 MHz | | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB | | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | TX Codec: A | | | | Name: B210 TX dual DAC | | | | Gain Elements: None

6 years, 8 months

LimeSDR+OSMOCOM (OSMO-BTS, OSMO-BTS-TRX, sip, etc.) on Winodws/Linux

by Даниил Догару

Hello! Please help me to run projects like GSM Base Station and others on my LimeSDR. I have only notebook on Windows (can lauch Linux on VirtualBox) and LimeSDR. I have spent much days and nights and even still cant run anything! I am very new to Linux, its strange builds, dependences, cross-compliers etc. I just can do something in terminal (CMD) step-by-step. Please I need a full step-by-step guide or ready IMAGE to run PREBUILD LIVE-CD so I can run .iso at virtual box. Please help me,I am very need to do things like in this videos: https://youtu.be/LV-CRJWC5_o or https://youtu.be/QOu3xNahmqI

6 years, 8 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC October 2018