OpenBSC July 2018

openbsc@lists.osmocom.org

15 participants
26 discussions

Cell Broadcast Feature
by Ron 31 Jul '18

31 Jul '18

Hi Community, Does anyone tried to use the Cell Broadcast feature in osmo? https://osmocom.org/projects/cellular-infrastructure/wiki/Cell_Broadcast Is there specific SDRs that supports this feature? Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

2 2

Re: Cell Broadcast Feature
by Vadim Yanitskiy 31 Jul '18

31 Jul '18

Hi Ron, > Does anyone tried to use the Cell Broadcast feature in osmo? > Is there specific SDRs that supports this feature? I have not tried personally, but I would like to clarify one thing. CBCH is implemented in the higher *software* layers, so it doesn't depend on a specific SDR device. The problem is that it isn't (yet) implemented for osmo-bts-trx, a BTS variant for SDR devices... Moreover, I believe it should be quite easy to implement this, so any patches are welcome ;) With best regards, Vadim Yanitskiy.

2 1

Rationale behind ipa_ccm_idtag_parse_off() ?
by Harald Welte 31 Jul '18

31 Jul '18

Hi Holger, I'm getting back to the following libosmocore commit introduced in 2015: > commit f558ed4bb9c0f00997b8f97c2b251a574c1a64c4 > Author: Holger Hans Peter Freyther <holger(a)moiji-mobile.com> > Date: Tue Jun 2 15:52:06 2015 +0200 I can see what you are doing, but I have absolutely no idea as to why. AFAICT, the IPA CCM ID TLVs have the following structure: * 16bit length field * one byte tag * optional payload The length field *includes* the tag, so the actual payload length is the value encoded in the length field minus one. This means that the existing/classic ipa_ccm_idtag_parse() always returns one byte too much for the length of the IPA payload. I'm trying to address this in https://gerrit.osmocom.org/#/c/libosmocore/+/10216/ Your commit introduces ipa_ccm_idtag_parse_off(), which introduces a noffset field. However, that offset is used not only to compute the actual "payload" size, but it's also used for computing the subsequent CCM information elements. Hence, I cannot use any non-zero offset to parse a CCM blob. I also don't see any of our code using the ipa_ccm_idtag_parse_off() function, except the test case - where the test case seems to use a different encoding as seen on the wire, i.e. it uses only a single-byte length field. So if the function was just added for that test case, why not structure the data used in the test to reflect the on-the-wire protocol reality? There must be some genius rationale behind it, but I'm unable to figure it out. Maybe you still remember? 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)

2 5

4G / LTE and osmocom
by Ruben Undheim 30 Jul '18

30 Jul '18

Hi, The OpenBSC tools have turned into an impressive collection of tools. It is great to see this huge effort being done successfully! I was searching around on the osmocom site for information about LTE. Either, I am very bad at searching, or there is not so much information about that subject. I was wondering about the plans for LTE, if there are any such plans? I am writing this taking into account that in the country where I live, the major telecom providers plan to shut down the 3G infrastructure already next year, leaving only 2G and 4G running. In some years, they also want to shut down 2G (which I have heard has already been done some places across the Atlantic) I found a few other projects related to LTE: nextepc [1] and srsLTE [2]. I see that nextepc has been mentioned in a thread related to OsmoDevCon 2018, but I cannot see so much more information. Is the plan maybe some time to incorporate srsLTE and nextepc into osmocom infrastructure? Is there currently any cooperation? Or will there be some new and fresh LTE code in osmocom? Mainly, I was just wondering whether you can shed some light on / discuss this subject. Thank you very much. Best regards Ruben Undheim [1] https://github.com/acetcom/nextepc / http://nextepc.org/ [2] nhttps://github.com/srsLTE/srsLTE.git

3 2

Reflashing ip.access nano3G
by Ernesto Sanchez 25 Jul '18

25 Jul '18

Hello, I bougth one ip.access nano3G in ebay, it seem to have a custom firmware for an operator that does not work in my country I want to know how to reflash it with the correct firmware to run openbsc. Can anybody help me? Best regards and a lot of thanks in advance.

4 10

gnumonks.org + people.osmocom.org downtime today
by Harald Welte 24 Jul '18

24 Jul '18

Hi! I will be doing extensive hardware maintenance + upgrades today in a data center, which means that gnumonks.org and some other related systems will be offline for some amount of time today, particularly during the morning and early afternoon (MESZ time zone). The only Osmocom system/service affected is people.osmocom.org. It's just likely that you will receive notifications about e-mail delays to my personal e-mail address, but those will be automatically re-transmitted after the systems are back online. Regards, Harald -- - 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)

1 0

merges to osmo-bsc master
by Neels Hofmeyr 23 Jul '18

23 Jul '18

Hey guys, I'm a bit disappointed that I see more merges to osmo-bsc master that tweak MGCP and codec preferences, moving things around files and so on. Please please do not merge this kind of stuff now, I really cannot use any of that while I'm turning insane to finally get the osmo-bsc refactoring out of the door. It's really mean to load merge conflicts on top of that. If fixes really need quick merging, please do everything in your might to AVOID moving functions around and changing file names. That's ... yeah, you get the picture. What is also more than welcome is to work on the branch tip of neels/inter_bsc_ho and apply cosmetic moves to that. Just please not between current master and the refactoring. (And to test that branch would also be welcome, if time permits.) Another alternative is to *talk* to me. Many thanks. ~N

1 1

pySim pytlv dependency
by Neels Hofmeyr 19 Jul '18

19 Jul '18

Hi Philipp, just now I'm trying to use pySim to read a SIM card, but I notice: ImportError: No module named pytlv.TLV I can find no pytlv in the debian packaging; and I notice this dependency was added only recently. When going back to 859e0fd1ce08699930064c12fb9f7908ef972b50 I can use pySim fine without that. a) I think the readme should hint at dependencies that pySim requires, which should include pytlv and where to find it. b) In python, it is easy to import pytlv only in case it is actually used, which would simplify dependencies for users that don't need to "get file/record length from FCP (USIM)" -- would that make sense? What are your thoughts? ~N

3 2

posting changes to existing patches (re large osmo-bsc patch)
by Neels Hofmeyr 19 Jul '18

19 Jul '18

TLDR: Tried to find another way of managing changes to a large patch on gerrit by submitting a merge-commit, but turns out not so useful. Just sharing findings. When I fix and change the current large osmo-bsc refactoring patch, on the one hand I'd like to squash new changes into it to commit the correct result right away. On the other hand, I want to keep the new changes in separate reviewable bits, so that reviewers don't need to read the entire patch again, and so that the new changes can be reviewed one by one, separately. So far my strategy was to add a new patch set for each small change. Now I thought it might make sense to have a non-fast-forward merge combining commits and review that. I tried it in the sandbox repos. Turns out that gerrit will have one patch for the merge-commit including the smaller commits, showing all combined changes. However, there will also be separate patches in the list for each single part of that merged commit. So there will be a series of small commits onto current master that need to be reviewed and merged one-by-one. And in the end that is followed by one basically useless merge-commit; meaning, if we got as far as accepting the smaller parts of that merge, we don't need to also merge that empty merge-commit, master already has gotten the smaller bits as separate commits. So the conclusion is that indeed pushing new small patch-sets onto the same large commit makes the most sense, and where changes stand on their own, separate follow-up patches make sense. ~N

1 0

BSC LCLS tests
by Neels Hofmeyr 17 Jul '18

17 Jul '18

Hi Philipp, I notice that 5 of the LCLS tests in ttcn3_bsc_tests fail saying "unexpected number of MGW-MDCX transactions" pass->FAIL BSC_Tests_LCLS.TC_lcls_gcr_bway_connect pass->FAIL BSC_Tests_LCLS.TC_lcls_gcr_bway_connect_hr pass->FAIL BSC_Tests_LCLS.TC_lcls_gcr_bway_codec_mismatch ... pass->FAIL BSC_Tests_LCLS.TC_lcls_connect_break pass->FAIL BSC_Tests_LCLS.TC_lcls_connect_clear It appears that your osmo-ttcn3-hacks change "BSC_Tests: count MGCP operations in as_media" lacks the proper MGCP operation counts for the LCLS tests? (The tests have been broken for four days) https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/test_resu… Could you fix that plz? Thanks! ~N

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2018