OpenBSC April 2024

openbsc@lists.osmocom.org

11 participants
12 discussions

by mosbah abdelkader

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

4 weeks

dynamic traffic channels

by Neels Hofmeyr

On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels

1 month

E1 to IP with iCE40 E1 USB interface

by Alina Androne

Hello, How can I utilize the iCE40 E1 USB adapter to transition from E1 to IP in a GSM network, connecting a physical Siemens BSC (which has a BTS connected) to OsmoMSC? Only the BTS and BSC are physical. I already have osmo-e1d installed. Should I use osmo-e1d or dahdi version for this transition? What would be the best approach to begin the process? Regards, Alina

1 year

Question about connecting OSMO-MSC to MME from Open5Gs

by Hennig, Lilly

Hello everybody, I was trying to setup an OSMO-MSC with an Open5Gs-Corenetwork, so I can send SMS to different UEs. Unfortunately the OSMO-MSC does not connect to the MME of the Open5Gs-Core and I do not find any installation guide for this specific setup. For your information: The Open5Gs-Core runs on a Laptop and I build the Software from source (4G and 5G components). The MSC should run on the same Laptop. Therefore I would like to ask you, if you can tell me, which other components besides of the OSMO-MSC I possibly have to install and how I should configure this components and the components of the core. Many thanks in advance! Best regards Lilly Hennig

1 year, 1 month

Is anyone using the official Osmocom rpm repositories?

by Oliver Smith

Dear mailing list, as announced in https://osmocom.org/news/246, the rpm packages for CentOS 8 / AlmaLinux 8 are unmaintained. sysmocom is currently still ensuring that the rpm binary packages build from the rpm spec files we have in our git repositories. But this is also significant effort that we would rather spend elsewhere, and so we are considering to stop providing rpm builds altogether and possibly removing these spec files from our git repositories. This affects the official Osmocom binary package repositories (nightly and latest) for CentOS 8/AlmaLinux 8 and openSUSE Tumbleweed. Stable versions of Osmocom programs are also in openSUSE's official repositories and can be installed from there. So, is anyone using the official Osmocom rpm repositories? As OsmoDevCon is coming up this weekend, we can also discuss it there, feel free to talk to me about it. Best regards, Oliver -- - Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Siemensstr. 26a * 10551 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

1 year, 1 month

GSMTAP new version (3?)

by Mauro Levra

Dear Osmocom developers, In our project we have been using the gsmtap pseudo-header to store UMTS and LTE signalling traces in pcapng format. This is very efficient compared to our previous implementation based on DLT_USER, and thanks to the gsmtap dissector, it allows any *shark app to read our output file. When looking for the proper type and sub_type for NR signalling traces, I discovered they are not yet part of the standard. I found several threads of discussion about this, from about 2017 onwards, and I understand it is a matter of time and resources if the version 3 of GSMTAP has not been released. The most interesting feature I have read about is the ability to extend the header with a TLV approach. EARFCN, eNodeB-ID, PCI, are useful metadata we would like to add to our traces. In an ideal world, I would like things to be put in motion so that a new version of GSMTAP could see the light. More humbly, I ask you what kind of help is needed. Are you waiting for a draft specification? Are all requirements well known? I suppose that LTE and NR are not the main focus today for liboscmocore development, but there are many projects out there waiting for the GSMTAP format to be updated. Thanks! Mauro

1 year, 1 month

error in libosmosccp

by Sandeep Kumar

Dera Team, I am facing this error. [root@ip-172-31-27-63 libosmo-sccp]# ./configure.ac ./configure.ac: line 1: dnl: command not found ./configure.ac: line 2: syntax error near unexpected token `[libosmo-sccp],' ./configure.ac: line 2: `AC_INIT([libosmo-sccp],' [root@ip-172-31-27-63 libosmo-sccp]# Kindly help here . Thanks . Regards, Sandeep Malik

1 year, 1 month

New Themyscira specifications for enhanced RTP transport in GSM RAN

by Mychaela Falconia

Dear Osmocom community, About a year ago I published this specification: https://www.freecalypso.org/specs/tw-ts-001-v010001.txt TW-TS-001 is a spec, written in 3GPP language style, for enhanced RTP transport of FR and EFR codec frames in an IP-based GSM RAN. I got OsmoBTS support for this RTP extension on branch falconia/rtp_traulike, but I never submitted it to Gerrit for mainlining: when I mentioned it in OsmoDevCall in 2023-06, the feedback from Harald was that the extension would need to be somehow requested from the CN via signaling, rather than manually switched on via OsmoBTS local vty. Since then I have familiarized myself with 3GPP specs for AoIP user place (TS 48.103 and TS 26.102 it refers to), and I see the problem with my initial "brute force" method: when 3GPP specs explicitly call for standard RTP formats at the AoIP interface, intentional deviations from that standard need to be negotiated/signaled in some clean manner. So here is my new solution: https://www.freecalypso.org/specs/tw-ts-001-v010100.txt https://www.freecalypso.org/specs/tw-ts-002-v010100.txt https://www.freecalypso.org/specs/tw-ts-003-v010001.txt There are 3 new specs in the above set: * The new version of TW-TS-001 clarifies some deficiencies in the original, and refers to TW-TS-003 for how the enhanced RTP format is to be invoked at the AoIP interface. * TW-TS-002 is a new spec that does for HRv1 codec what TW-TS-001 does for FRv1 and EFR. The enhanced RTP payload format here is an extension of RFC 5993, which I named super-5993. * TW-TS-003 is an extension to BSSMAP for communicating the use of enhanced RTP payload formats between MSC and BSS. I will now be preparing some patches for TW-TS-003 support - see you in Gerrit code review soon. :-) With love and greetings from Themyscira, Mother Mychaela

1 year, 1 month

Looking for captures of TRAU-UL frame stream from E1 BTS

by Mychaela Falconia

Hello Osmocom community, Would anyone here happen to have a capture of a TRAU-UL frame stream from some historical E1 (or T1) BTS? And if no already existing UL capture is available, if I found someone with access to such equipment who would be willing to do a few tests for me, what would be the way to make such capture? I mean raw Abis UL capture, *not* converted to RTP or anything else, and because I don't have any T1/E1 hardware currently, I am not really familiar with Osmocom tools for working with such hw and what tap/trace/capture mechanisms are available. And yes, I see on the wiki page for OsmoDevCon that some E1 BTS hw will be present at the event - but my lack of an updated travel document from USCIS still precludes me from traveling anywhere outside of USA+Canada+Mexico territory. :( M~

1 year, 1 month

OsmoDevCon talk: Your favorite Osmocom related productivity tips and tools

by Oliver Smith

Hi all, I'm making a talk about tips and tools for doing more effective Osmocom related development. Some ideas I have for it currently: * how to build your own (deb, rpm) packages with OBS * how to run CI stuff (like the checkpatch linter) locally * running tcpdump over SSH and piping it into wireshark * finding what regression caused a ttcn-3 failure systematically Is there anything (within this list or other ideas) you would find particularly interesting, or boring? If you have a couple of tips or tools to share, and would like to present them yourself: let me know as well, then we could turn this into a quick lightning talk series with multiple presenters. Best, Oliver -- - Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Siemensstr. 26a * 10551 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

1 year, 2 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC April 2024