OpenBSC

openbsc@lists.osmocom.org

4315 discussions

osmo-pcu, osmo-bts, osmo-bsc releases with PCUIF 12
by Oliver Smith 13 Dec '23

13 Dec '23

Dear mailing list, I'm looking into releasing a new osmo-pcu version to finish up OS#6198, and to have a release with the fix for OS#6191. Apparently that fix requires a new PCUIF version. And osmo-pcu master now has a check that requires the *exact* PCUIF version: https://cgit.osmocom.org/osmo-pcu/commit/?id=46140948d9800bca6a7b4299f08b25… pcu_i1_if.cpp: } else if (info_ind->version != PCU_IF_VERSION) { fprintf(stderr, "PCU interface version number of BTS/BSC (%u) is different (%u).\nPlease use a BTS/BSC with a compatble interface!\n", info_ind->version, PCU_IF_VERSION); exit(-1); } So we will need to create releases of osmo-bts and osmo-bsc with the new PCUIF version as well. As this is a breaking change, I think we should bump the major version, and that in turn makes more sense with tagging current master instead of cherry picking a few patches. So I propose to do the following: * tag a new libosmocore patch release with the few patches required for osmo-pcu, osmo-bts and osmo-bsc master (see their TODO-RELEASE). * tag major releases of osmo-pcu, osmo-bts and osmo-bsc from their current master Does that make sense? Best regards, Oliver -- - Oliver Smith <osmith(a)sysmocom.de> https://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

4 4

AMR mode-set
by Neels Hofmeyr 12 Dec '23

12 Dec '23

Hi Nick, I just read your post https://nickvsnetworking.com/tales-from-the-trenches-mode-set-in-amr/ and just when it really gets interesting, the article ends =) I'm working at osmocom.org and am currently figuring out how TH we are supposed to communicate the AMR mode sets across 2G + 3G mobile networking on the one side and SDP/SIP+RTP on the other side. My plan was to do it like choosing codecs: One side sends all its capabilities, the other responds with the own capabilites removing unsupported entries. Now I read in your post that mode-set is take-it-or-leave-it. The interesting part is the practical problem that arises from it: e.g. on a 2G mobile network, i'm allowed to choose up to four AMR rates, no more. When on a half-rate channel, then specific rates (12k2, 10k2) are not supported. Otherwise I can tell the 2G BTS and the phone to pick various mode-set combinations. So why not send a full mode-set of 0,1,2,3,4,5,6,7 and the other call leg can then say "i'll pick these four", or something like that. With your spec references, it means that now I need to pick specific mode-set combinations in advance, and assign a different payload type number to each of them. The extreme example would be: a rtpmap:110 AMR/8000/1 a fmtp:110 mode-set=0 a rtpmap:111 AMR/8000/1 a fmtp:111 mode-set=1 a rtpmap:112 AMR/8000/1 a fmtp:112 mode-set=2 ... a fmtp:117 mode-set=7 a fmtp:118 mode-set=0,1 a fmtp:119 mode-set=0,2 a fmtp:120 mode-set=0,3 a fmtp:121 mode-set=0,4 ... a fmtp:99999998 mode-set=0,1,2,3,4,5,6 a fmtp:99999999 mode-set=0,1,2,3,4,5,6,7 Obviously nonsense, but you catch my drift. So what is the solution then? In 2G GSM I have half-rate and full-rate channels; AMR-FR and AMR-HR should be able to interop. So if one FR side offers mode-set=0,2,4,7 then the HR side may return mode-set=0,2,4 to leave only HR compatible rates. Well, no. If not that, then: I probably need to create one RTPMAP entry for full-rate compatible operation and another entry for half-rate compatible operation. 111:mode-set=0,2,4,7 112:mode-set=0,2,4 Also some hardware supports only 12k2, so then I need to add an extra entry for only 12k2. But I have to so not only on the side that has the 12k2 limit, but on the side that wants to interop with it! Because if the peer doesn't offer a single "mode-set=7", then the only-12k2 supporting side must reject the entire call. 111:mode-set=0,2,4,7 112:mode-set=0,2,4 113:mode-set=7 The question is, were the specs in good intentions, but in practicality it is mayhem of exploding nr of permutations, and maybe your MGW made a sane choice of not diving into this madness? Thanks for your feedback on this! ~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

1 0

osmo-mgw: explicit fmtp vs. autodetection
by Neels Hofmeyr 08 Dec '23

08 Dec '23

Hi all, I have a request for comments regarding osmo-mgw, particularly the fmtp for AMR octet-align mode and the two GSM-HR variants. We are currently reviewing/writing patches to allow flexible use of fmtp in libosmo-mgcp-client. The plan is to be able to indicate which GSM-HR variant (RFC5993 or 3GPP TS 101.318) is in use. Also we are fixing the ability to indicate AMR mode (octet-align=1 vs 0) properly, per payload type nr instead of once per SDP body. Example of MGCP with SDP, showing two codecs, AMR as 112 and GSM-HR as 111, each with a fmtp as I'm discussing now: CRCX 2 7@mgw MGCP 1.0 C: 2 v=0 c=IN IP4 123.12.12.123 m=audio 5904 RTP/AVP 112 111 a=rtpmap:112 AMR/8000/1 a=fmtp:112 octet-align=1 a=rtpmap:111 GSM-HR-08/8000/1 a=fmtp:111 gsm-hr-format=3gpp-ts-101.318 a=ptime:20 That means that each MGW client tells osmo-mgw exactly what AMR and HR formats to send to the RTP peer, and also restricts exactly which format to expect from that RTP peer. So BSC and MSC need to know things about BTS and BSS, in advance: - the BSC needs configured knowledge of each BTS's octet-align and gsm-hr-format. - the MSC needs configured knowledge of what the BSC will do. - what if there are divergent formats in different BTS of a BSS, does MSC need to know that too? There is certainly no way to indicate octet-align nor HR variant in standard A interface proto. So far so complex, BUT: In practical testing, I see from logging that osmo-mgw is already quite capable of detecting which AMR octet-align mode and which HR format is actually arriving from the RTP peer (from the BTS...). I see this log line: DRTP NOTICE (rtpbridge/1@bsc0 I:FA1F785D) rx_rtp(44 bytes): Expected RTP AMR octet-aligned=1 but got octet-aligned=0. check the config of your call-agent! (mgcp_network.c:1525) And I'm thinking, where is the problem, just do what you need to do; all the information it needs to do the right thing is already available to osmo-mgw. So why even the need to configure {AMR octet-align|GSM-HR mode} in SDP? Idea: - the first RTP packet arriving is examined, and from then on the peer is known to use that format. - when later, an RTP needs to be forwarded back to that peer, we convert to the format that the peer uses, iff it is necessary. - for sanity we could hold back forwarding RTP before the details of the recipient are known, i.e. wait for each peer to send the first RTP to MGW. Example for an RTP stream in GSM-HR format: A MGW B |--HR(3gpp)-->|--x drop | (don't know B's preference yet, cannot send) | [3gpp]| | (now know A uses the 3gpp format) | |<--HR(rfc)--| | |[rfc] | (now know B uses the RFC format) | [convert] | |<--HR(3gpp)--| | |--HR(3gpp)-->|--HR(rfc)-->| |<--HR(3gpp)--|<--HR(rfc)--| There is an important difference between AMR octet-align and GSM-HR: - 'octet-align=(0|1)' is a defined standard fmtp that already exists, and it may be necessary to forward this accurately to PBX. We may not get around having to explicitly set this. - GSM-HR format is a new fmtp we are inventing now. So the idea is most relevant here: if we can always just autodetect the right thing to do, then why introduce a non-standard fmtp? (plus all the MGW client vty cfg needed) What do you think? 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

3 3

Binary packages: changes in supported distributions
by Oliver Smith 05 Dec '23

05 Dec '23

Hello various Osmocom mailing lists, the official Osmocom binary packages will not be built anymore for the following distributions starting at 2024-02: * Raspberry Pi OS 64-bit (use Debian_12 etc. instead) * Ubuntu 23.04 (Ubuntu 23.10 and LTS 20.04/22.04 feeds are available) * openSUSE 15.4 (openSUSE Tumbleweed feed is available) * Debian Testing (Debian Unstable and 12-10 feeds are available) For Raspberry Pi OS 64-bit users, make sure to adjust your /etc/apt/sources.list.d as described here to switch to a Debian aarch64 feed: https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds See the new linux distributions article for information on how long we plan to keep building packages for each distribution: https://osmocom.org/projects/cellular-infrastructure/wiki/Linux_distributio… Let me know if you have questions. Best regards, Oliver -- - Oliver Smith <osmith(a)sysmocom.de> https://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

1 0

Questions on OSMOCOM & real nodes integration
by jheyrendt.ext＠orange.com 30 Nov '23

30 Nov '23

Hi We set up a full Osmocom platform, with an Ettus USRP for SDR. All works well. Congratulations to Osmocom developers ! But now we want to use "real" nodes concerning MSC, MGW, HLR, SGSN & GGSN. Do you think it is possible ? Concerning the BSC-MSC association, do we need to use an SG (osmo-stp) ? or could we establish a Point To Point BSC-MSC ? SUA ? Concerning MGW, is there a way to use our MGW ? At this time, with Osmocom corposants, we can see RTP traffic between BTS-TRX and MGW, and some MGCP traffic between (BSC - local MGW) and MGW, and some MGCP traffic between osmo-MGW and osmo-MSC. Is there a way to have a "more standard" architecture: no traffic between BTS and MGW, and MGW controlled by MSC ? Do we have to more study TRAU, AoIP ? Concerning the Gb, do you think that it 'll work if we configure the Gb on a real SGSN connected to the osmo-pcu, hosted on the osmo-bts-trx? Many thanks in advance, Best regards Jean-Marc Orange Restricted

3 6

OsmoMSC: full proper codecs negotiation
by Neels Hofmeyr 20 Nov '23

20 Nov '23

It is my pleasure to inform that I have a WIP patch for OsmoMSC that allows, for the first time, full MO<->MT codecs negotiation to flexibly achieve TFO (Transcoding-Free Operation). It would be great if OsmoMSC users could give the patch a spin (in a setup that is allowed to fail because of the patch) and see if 2G calls now adjust the MO call leg to MT's codecs limitations for you. Looking forward to feedback! This task was idling on my list because I assumed it would be a big effort, but now I realized that it is actually simple, not even a new FSM state required. So I could no longer resist to finally complete this long long quest. The result is this WIP patch: https://gerrit.osmocom.org/c/osmo-msc/+/35051 Related patch series, uncluding ttcn3 test: https://gerrit.osmocom.org/q/topic:reass This patch requires full SDP on MNCC, so if using osmo-sip-connector, it should be current master -- the relevant patch was merged but is not released yet: https://gerrit.osmocom.org/c/osmo-sip-connector/+/16222 Before this patch, MO was eternally stuck on the initially assigned codec. Now we adjust MO's codec if MT needs it. (MT already intelligently chooses codecs before this patch.) For example, if MO is AMR capable and MT is not, - the MO side will start out with assigning an AMR codec (not matching). - Once MT responds (MNCC_ALERT_REQ), the MO side notices that MT does not support the assigned codec. It sends another Assignment Command to the BSC, offering only the codecs that MT supports. - If MO has at least one matching codec (say GSM-FR), the result is a TFO call using a matching codec. We still need to check: - does OsmoBSC play along nicely with the re-assignment (it should AFAICT). - effects on MGCP: there may now be more codecs than just the assigned one in the MGCP towards the MGW. See if that checks out. - effects on 3G: make sure the feature doesn't confuse IuUP handling. The patch passes all MSC_Tests.ttcn for me (but that doesn't necessarily imply proper codecs choices, the tests are not very strict there it seems). ~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

2 2

OsmoDevCall on Nov 15, 2023: Calypso history: From TI to FreeCalypso to USA PSTN
by Harald Welte 15 Nov '23

15 Nov '23

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: (today) November 15, 2023 at 20:00 CET where: https://osmocom.org/OsmoDevCall (Big Blue Button) This time, @falconia will be presenting on Calypso chipset history and development boards, from TI to FreeCalypso This meeting will have the following schedule: 20:00 meet + greet 20:10 topic 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)

1 0

Network communication equipments for inquiry <16/10/2023 17:55>
by Yolanda from Longriseequipment 16 Oct '23

16 Oct '23

1 0

Osmo-CBC: (bts=0) Rx CBSP RESET: clearing all state; disabling broadcast
by Sipos Csaba 26 Sep '23

26 Sep '23

Dear List, I tried to set up Osmo-CBC with a Nokia MetroSite BTS according to the wiki. But every time the CBSP clinet of the BSC connects to the CBC server, the BSC log indicates: DCBS cbsp_link.c:150 CBSP Client connected to CBC: (r=127.0.0.1:48049<->l=127.0.0.1:46133) DCBS smscb.c:805 (bts=0) Rx CBSP RESET: clearing all state; disabling broadcast Same time on the CBC: <0002> cbsp_link.c:265 New CBSP link connection from 127.0.0.1:46133 <0002> cbsp_link_fsm.c:181 local-bsc: RESTART (CBS) but re-sending not implemented yet The BTS is configured with CCCH+SDCCH4+CBCH, and these are the relevant sections: osmo-cbc.cfg: cbc unknown-peers reject ecbe local-ip 127.0.0.1 local-port 12345 cbsp local-ip 127.0.0.1 local-port 48049 sbcap local-ip 127.0.0.1 local-port 29168 peer cbsp local-bsc mode server remote-port 46133 remote-ip 127.0.0.1 osmo-bsc.cfg: cbc mode client client remote-ip 127.0.0.1 local-ip 127.0.0.1 local-port 46133 Every other CS service is working fine on the BTS. Is there anything else I might have missed? Regards, Csaba

3 5

OsmoDevCall on Sept 20, 2023: Interconnecting an Osmocom GSM network to USA PSTN
by Harald Welte 18 Sep '23

18 Sep '23

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: September 20, 2023 at 20:00 CEST where: https://osmocom.org/OsmoDevCall (Big Blue Button) This time, @falconia will be presenting on Themyscira Wireless: a case study in interconnecting an Osmocom GSM network to USA PSTN This meeting will have the following schedule: 20:00 meet + greet 20:10 topic 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)

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC