OpenBSC

openbsc@lists.osmocom.org

8 participants
4276 discussions

CBS + Osmocom + LimeSDR-Mini
by Radiarisainana Sitraka 13 Feb '20

13 Feb '20

Hello, I'm testing CBS LimeSDR-Mini with osmocom by following this Version 10 - History - Cell Broadcast - Cellular Network Infrastructure - Open Source Mobile Communications | | | | Version 10 - History - Cell Broadcast - Cellular Network Infrastructure ... Redmine | | | h4. make sure your related BTS is configured to use a channel combination with CBCH For using a combined CCCH with SDCCH/4 and CBCH you can use the following example snippet as part of osmo-bsc.cfg: network bts 0 trx 0 timeslot 0 phys_chan_config CCCH+SDCCH4+CBCH

1 0

Feedback to GSUP Proxy Cache concept
by Oliver Smith 24 Jan '20

24 Jan '20

Hi Neels, > D-GSM proxy cache -- if you have the time, feedback on this design document would be appreciated: http://git.osmocom.org/osmo-hlr/commit/?h=neels/dgsm&id=8071c561405a031f204… > (when that commit is checked out, building osmo-hlr with manuals enabled should render the ladder diagrams in proxy_cache.adoc, which illustrate what I'm planning to implement) > (and disregard "(7) Skip the Insert Subscriber Data", as explained in the prose) I like that the key of the home HLR is not shared with the proxy HLRs. All in all, it sounds like a very smart solution! Some notes: * In the ladder diagrams, it shows that the AKAs are cached in both the MSC and the HLR. Why not just cache them in the HLR? * It might be a good idea to make AKA reuse optional with a VTY config option? * Potential use case: phone is home in village A, gets turned off, owner travels to village B with the phone, the link to village A is down. Phone gets turned on, then there will be no AKAs cached in village B's (proxy) HLR and the LU will fail. But there does not seem a way around this without sharing the keys (or without spaming other HLRs with AKAs for all subscribers in the HLR that they might use in the future, but that would just waste traffic). 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

2 1

build2.osmocom.org hardware replacement
by Harald Welte 22 Jan '20

22 Jan '20

Dear Osmocom community, in recent weeks (at least since mid-december) we've had some stability issues with build2.osmocom.org, the physical machine that runs the build2-deb8build-ansible and build2-deb9build-ansible LXCs used heavily by our jenkins. I've had to reset the machine, and now we finally have asked the hosting company to perform a hardware replacement. This has happened about 3 hours ago, and I hope the stability problems are gone now. Let me know if you still see anything odd related to build2. Regards, Harald -- - 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

Osmocom CNI release 202001
by Pau Espin Pedrol 09 Jan '20

09 Jan '20

Dear all, I'm pleased to announce new tagged releases for Osmocom Cellular Network Infrastructure components. libosmocore 1.3.0 osmo-gsm-manuals 0.3.0 osmo-pcap 0.1.2 osmo-ggsn 1.5.0 libosmo-abis 0.8.0 libosmo-netif 0.7.0 libosmo-sccp 1.2.0 osmo-sip-connector 1.4.0 osmo-hlr 1.2.0 osmo-trx 1.2.0 osmo-bts 1.2.0 osmo-pcu 0.8.0 osmo-mgw 1.7.0 osmo-iuh 0.6.0 osmo-bsc 1.6.0 osmo-msc 1.6.0 osmo-sgsn 1.6.0 openbsc 1.3.2 Tags for related Openembedded meta layers have also been updated and are waiting to be merged, hopefully today, and will be available in branch 201705. Other related components such as libgtpnl or libsmpp34 had no development at all since last release cycle so they don't show up here. As a reminder, last release cycle was done around August 2019. Have fun, -- - Pau Espin Pedrol <pespin(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 * Geschaeftsfuehrer / Managing Director: Harald Welte

2 2

Osmo Bsc (Seperate CNI) with Asterisk network busy!!
by Garrett Allen 02 Jan '20

02 Jan '20

Hi All I've used osmo-bsc in non standalone mode ie seperate components and all works fine voice and sms work as should. However when introducing. sip connector with asterisk the handsets will not make voice calls they just constantly respond network busy. I'm using osmo bts-trx with osmo-trx-lms on raspbian 10 below is Asterisk config. Any help would be appreciated. Gar [GSM] type=friend host=127.0.0.1 dtmfmode=rfc2833 canreinvite=no disallow=all allow=gsm context=gsmsubscriber port=5062

3 7

limesdr mini - osmo cni
by ah med 25 Dec '19

25 Dec '19

HI I just tried to use limesd mini with osmocom cni and i used this script to launch all the items : #!/bin/sh cmd="${1:-start}" set -ex systemctl $cmd <https://twitter.com/search?q=%24cmd&src=cashtag_click> osmo-hlr osmo-msc osmo-mgw osmo-ggsn osmo-sgsn osmo-stp osmo-bsc osmo-hnbgw osmo-pcu osmo-trx-lms osmo-bts-trx everything seems work fine,only the osmo-trx-lms : osmo-trx-lms[7995]: Sun Dec 8 18:02:03 2019 DLMS <0003> LMSDevice.cpp:94 > [tid=140437169072832] Reference clock 40.00 MHz > osmo-trx-lms[7995]: Sun Dec 8 18:02:03 2019 DDEV <0002> > LMSDevice.cpp:192 [tid=140437169072832] Init LMS device > osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DDEV <0002> LMSDevice.cpp:99 > [tid=140437169072832] Sample Rate: Min=100000 Max=3.072e+07 Step=0 > osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DDEV <0002> > LMSDevice.cpp:228 [tid=140437169072832] Setting sample rate to 1.08333e+06 4 > osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DDEV <0002> > LMSDevice.cpp:234 [tid=140437169072832] Sample Rate: Host=1.08333e+06 > RF=3.46667e+07 > osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DMAIN <0000> > LMSDevice.cpp:209 [tid=140437169072832] Antennas configured successfully > osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DMAIN <0000> Threads.cpp:117 > [tid=140437098583808] Thread 140437098583808 (task 8127) set name: > CtrlService0 > osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DMAIN <0000> > osmo-trx.cpp:528 [tid=140437169072832] -- Transceiver active with 1 > channel(s) > osmo-trx-lms[7995]: Sun Dec 8 18:02:05 2019 DTRXCTRL <0001> > Transceiver.cpp:773 [tid=140437098583808][chan=0] command is 'POWEROFF' > osmo-trx-lms[7995]: Sun Dec 8 18:02:05 2019 DTRXCTRL <0001> > Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP POWEROFF > 0' > i am using the default .cfg files ! Thanks.

3 15

distributed GSM / some thoughts
by Harald Welte 14 Dec '19

14 Dec '19

Hi Oliver, Neels, community, I had some comments on the D-GSM work that didn't really fit directly to the gerrit code review, and I thought I'd post it here. == DNS zone / .msisdn suffix === One question I had was regarding the use of the .{msisdn,imsi} TLD. I would argue it is probably besser to use something that fits within the existing DNS hierarchy without contesting IANA's authority on gTLDs. Historically, ETSI/3GPP made the mistake of using ".gprs" for resolving APNs on the GRX. This was later changed to something with 3gppnetwork.com or the like, hwere that domain would actually be registered by 3GPP with normal domain registrars, but without any publicly accessible zone records. This way the name is reserved in the public hierarchy and no risk of clashes. I'm not sure how much of a concern this is to us, given that our use case is much more niche than the GRX. However, the "cost" is probably rather small to change this to something like .{msisdn,imsi}.dgsm.osmocom.org ? Sure, the packets will get larger by a few bytes, but given all the other overhead I think it's not really going to have any impact? What are your thoughts on that? == MSISDN format == Another thought is whether or not there are any concerns regarding the MSISDN format. Historically, this is one of the weaknesses of OsmoMSC, inherited from the OpenBSC days where we just thought in terms of PBX extension numbers. In reality, a MSISDN consist of a TON (type of number), NPI (numbering plan indicator) and the related digits. IIRC, in the TON one can also specify if it's supposed to be national or international, i.e. if it's prefixed with the country code or not. It would be great to make sure that the format used in the mDNS queries is somewhat standardized, if not at least only by the documentation requiring that all queries should be done in fully qualfiied form with country code present. NPI is sort-of bogus as IMOH E.164 is the only one applicable for MSISDN. Any thoughts? == The use of 'age' vs. absolute timestamp == In my original D-GSM idas I always thought we'd send an absolute UTC timestamp when a given HLR/MSC has ever seen that subscriber. The idea here being that any rural GSM network will have some kind of GNSS recevier for clock stability in the BTS anyway, and one can hence assume that timestamps are synchronized. The advantage of a relative 'age' is obvious: You don't care about the absolute clock value being correct anymore. The potential downside is that propagation delay might matter. If you have a rather slow / loaded geostationary sattelite link from one village, but a faster terrestrial link from another village, the 'age' will be ambiguous while an absolute timesetamp wouldn't have that. Given that the delays we're talking about are probably all sub-second or maybe possible about 1s, it's probably not a problem. == GSUP keepalives / connection loss detection == In the presence of unreliable back-haul mesh between villages, the GSUP connection can also not be seen as reliable. We would expect to see TCP stalls due to packet loss, etc. Have you considered this in your implementation and/or done any testing based on simulated lossy networks to ensure we properly use either TCP keepalives or IPA application-level PING/PONG to detect lost connections and recover from such situations (by closing the old and re-establishing)? Unreliable networks can be easily simulated by Linux built-in 'tc netem' for providing configurable packet loss / latency / jitter. I also saw some comments / code related to "if a second connection using the same IPA ID arrives, we're screwed" (paraphrasing here). I would expect this not to be uncommon even if every MSC/HLR out there is configred correctly exactly because e.g .the remote MSC/HLR has already decided that the TCP/GSUP is dead and starts to reconnect by performing a local-end release, while the "local" MSC/HLR still thinks the old connection is alive. If the old connection "wins" (i.e. is preferred) I see potential trouble here. Situations like that probably warrant some carefully designed tests to create exactly those situations. Regards, Harald -- - 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)

4 6

Re: [osmocom-event-orga] 36c3: GSM base stations wanted - Handing out 1 NanoBTS
by circle 04 Dec '19

04 Dec '19

Hey, yes, I ll drop one NanoBTS in Berlin, at Afra or Sysmocom before the first day of the conference. Im not sure, if Ill be able to do so this week. It actually belongs to Sysmocom / Harald. Best regards, circle ------ Dear all, 36c3 is going to happen soon, and as usually we're planing to setup our own GSM/UMTS network (LTE is to be discussed). While we do have enough UMTS NodeB units, we're looking for heroes who could sacrifice their GSM base stations (preferably sysmoBTS or nanoBTS) for the duration of the congress. Note that we're not considering SDRs (unless somebody with a strong aspiration wants to ensure proper clock distribution, filtering, power amplification, etc). Please let us know 1) how many (and what kind of) units we could borrow from you, 2) can you bring them to Leipzig before the first day, or can you drop them somewhere in Berlin (Sysmocom? AfRa?). Thanks! On behalf of the GSM team, Vadim Yanitskiy.

1 0

OsmoDevCon 2020 registration
by Harald Welte 02 Dec '19

02 Dec '19

Dear fellow Osmocom developers, I would like to invite all developers and contributors to Osmocom [sub]projects to register for OsmoDevCon 2020 (held on April 24th-27th, 2020 in Berlin). For details known so far, please check http://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020 Please enter your name at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020#Requested in case you would like to attend. Registering early allows proper planning. Thanks! Looking forward to meeting old and new Osmocom developers in April 2020. Regards, Harald -- - 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

request: osomocom git repo branch cleanup
by Harald Welte 30 Nov '19

30 Nov '19

Dear Osmocom developers, the number of branches in many repositories (most notably libosmocore) is growing to a rather large number, and I would like to encourage everyone to have a quick look about which branches can be deleted by now (and delete them, if no longer needed). Thanks! Regards, Harald -- - 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